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Abstract 


A  multiprogramming  operating  system,  designated^AFIT^ 
Multiprogramming  Operating  System  (AMOS) ,  for  the  AFIT 
Digital  Engineering  Laboratory  was  designed  at  the 
detailed  level  and  fully  implemented,  except  for  the 
assembly  language  routines.  The  requirements  were 

developed  in  the  works  of  Yusko,  Ross,  and  Huneycutt.  - - - 

This  thesis  effort  was  done  in  conjunction  with  the 
effort  of  Lt.  Paul  E.  Cruser .  ^  This  effort  covers  the 
detailed  design  and  implementation  of  the  overall  system, 
the  detailed  design  and  implementation  of  the  operating 
system  memory  manager,  and  the  specifications  for  the 
secondary  storage. 
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Introduction 


.  i 


I.  Scope  of  Project 


^  The  purpose  of  this  project  is  to  continue  the  design 
and  implementation  of  a  multiprocessing  operating  system 
for  sixteen-bit  microcomputers.  '  This  operating  system 
will  be  referred  to  as  the  AFIT  Multiproramming  Operating 
System  (AMOS)  (Ref.  1:1).  The  purpose  of  this  chapter  is 
to  give  a  brief  overview  of  operating  systems,  to  outline 
requirements  for  AMOS  that  have  been  defined  in  the 
previous  efforts  by  Ross  (Ref.  4)  ,  Yusko  (Ref.  5)  ,  and 
Huneycutt  (Ref.  1)  ,  to  outline  the  objectives  of  this 
project,  and  to  present  the  approach  to  obtain  the  stated 
objectives. 

One  definition  of  an  operating  system  (0/S)  is  "an 
organized  collection  of  systems  or  programs  that  acts  as 
an  interface  between  machine  hardware  and  users,  providing 
users  with  a  set  of  facilities  to  simplify  the  design, 
coding,  debugging,  and  maintenance  of  programs  while,  at 
the  same  time,  controlling  the  allocation  of  resources  to 
assure  efficient  operation."  (Ref.  2:1,2)  In  other  words, 
the  0/S  is  a  large  software  management  program  that  acts 
as  an  interface  between  the  user  and  the  computer  system. 


The  computer  system  could  include  the  hardware, 
application  programs,  and  control. 

Historical 

In  the  first  generation  of  vacuum-tube  hardware,  the 
procedure  for  the  operating  system,  which  <  -  nothing  more 
than  a  program  loader,  was:  a  loade  reads  in  an 
assembler?  the  assembler  assembles  into  abs  ate  code  user 
source  programs  and  library  routines;  the  assembled  code 
is  written  on  tape  or  cards,  and  a  loader  is  again  used  to 
read  these  into  main  storage;  the  absolute  code  of  the 
program  is  then  executed  (Ref.  2:7).  This  meant  that 
there  was  only  one  job  executed  at  a  time. 

In  the  second  generation  of  transistorized  hardware, 
the  operating  system  was  developed  into  a  sequential  batch 
processing  operating  system.  The  operating  system  made 
use  of  new  data  channels,  interrupts  and  used  auxiliary 
storage  efficiently  (Ref.  2:9).  This  type  of  operating 
system  still  only  allows  one  job  to  be  executed  at  a  time. 

Along  with  the  integrated  circuitry  of  the  third 
generation  came  the  multiprogramming  and  time-sharing 
methods  that  could  be  used  to  make  an  operating  system 
more  efficient  (Ref.  2:12).  Multiprogramming  is  based  on 
the  concept  of  concurrency;  that  is,  more  than  one  program 
can  be  executing  within  the  computer  system  at  the  same 


time  (Ref.  3:29).  Since  only  one  central  processor  is 
used  in  this  type  of  environment,  only  a  single  program 
may  be  executing  at  a  given  instant  in  the  central 
processing  unit  (CPU),  but  to  the  users  it  seems  as  if  all 
the  programs  are  executing  at  the  same  time.  This  is  done 
with  the  use  of  input/output  processing.  Multiprogramming 
systems  alternate  the  programs'  usage  of  the  CPU  according 
to  some  policy.  The  operating  system  determines  which 
program  is  ready  for  execution  and  then  allocates  the  CPU 
for  the  program. 

Time-sharing  systems  are  an  attempt  to  give  each  user 
a  personal  computer  while  efficiently  utilizing  the 
resources  of  a  relatively  expensive  machine.  All  user 
interactions  on  a  time-sharing  system  are  done  through 
on-line  terminals.  Two  requirements  for  a  time-sharing 
system  are  1)  the  response  time  has  to  be  maintained  at 
the  appropriate  level  of  the  human  attention  span  and  2) 
the  appearance  of  unrestricted  access  is  presented  to  the 
user  (Ref.  3 :29)  . 

The  concepts  of  multiprogramming  and  time-sharing  are 
complementary.  Most  minicomputer  systems  couple 
multiprogramming  capabilities  with  an  interactive 
time-sharing  capability  (Ref.  3:30).  An  example  of  such 
an  operating  system  is  UNIX  (Ref.  20). 


There  are  many  types  of  operating  systems  on  the 
market  today  for  all  sizes  of  computers.  They  range  from 
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the  simple  batch  to  the  complex  network.  These  operating 
systems  are  more  complex  than  the  original  ones  and  will 
become  more  complex  in  the  future  when  greater  needs  are 
pressed  on  the  operating  system. 


Review  of  Previous  Requirements 


This  thesis  effort  is  a  follow-on  to  three  previous 
thesis  efforts  that  were  under  the  direction  of  Professor 
Gary  B.  Lamont.  Ross  (Ref.  4)  and  Yusko  (Ref.  5)  were 
concerned  with  the  upper  level  design  of  the  operating 
system.  Huneycutt  (Ref.  1)  was  concerned  with  design  and 
implementation  of  the  file  management  of  the  operating 
system. 

The  previous  requirements  (given  by  Ross,  Yusko,  and 
Huneycutt)  are  followed  in  the  final  design  and  initial 
implementation  of  the  operating  system.  Eight 
requirements  for  AMOS  that  are  the  goals  for  the  initial 
implementation  are: 


Multiuser  support  for  at  least  four  concurrent 
users . 

Friendly  user  interface. 

Interuser  communication. 

Fair  allocation  of  system  resources. 

Meaningful  error  diagnostics. 


6.  Recovery  routine. 

7.  Minimal  device/user  utility  support  (Ref  1:11). 

8.  Provide  a  general  purpose  configurable  0/S  with 


full  documentation  to  aid  in  teaching  of  O/S 
courses . 

Although  the  Intel  8086  microprocessor  was  initially 
chosen  (Ref.  4,5),  the  Z8000  was  selected  (Ref.  1)  because 
it  offered  the  desired  support  that  was  not  provided  by 
the  8080.  The  Z8000  is  also  capable  of  discerning  between 
system  and  user  tasks  and  can  control  the  operations  being 
performed  for  the  users  (Ref.  1:16).  The  choice  of  the 
Z8000  will  be  covered  more  thoroughly  in  the  requirements 
chapter  (Chapter  2) . 

The  implementation  of  AMOS  will  be  written  mostly  in 
the  C  language.  Hardware  dependent  routines  will  be 
written  in  the  Z8000  Assembly  language.  The  reasons  for 
using  C  are: 

1.  It  is  a  structured  language. 

2.  There  is  C  source  code  for  an  existing  operating 
system  (UNIX)  (Ref.  20)  that  is  readily  available 
to  research. 

3.  The  C  language  is  less  restrictive  than  other 
high-level  languages  that  have  an  available 
compiler. 


The  modules  that  are  to  be  written  in  assembly 
language  will  have  to  be  rewritten  in  the  new  host 


computer's  assembly  language. 

Objectives 

The  objective  of  this  project  is  to  design  and 
implement  a  multiprogramming  operating  system  for  a 
sixteen-bit  microprocessor.  Top-down  methodology  is  the 
main  tool  for  design  and  implementation.  The 
implementation  of  AMOS  will  be  done  in  the  C  language,  as 
stated  earlier,  and  will  avoid  hardware  configuration 
dependency  (enhance  portability) .  The  only  hardware 
dependent  modules  are  those  written  in  assembly  language. 

Approach 

The  project  started  with  a  literature  search  and  review 
to  obtain  information  on  operating  systems  and  their 
development.  The  requirements,  for  the  most  part  are 
taken  from  References  1,  4,  and  5.  The  structure  of  AMOS 
will  be  modular  to  facilitate  testing,  maintenance,  and 
portability. 


AMOS  will  be  initially  implemented  on  the  Multibus 
Z8000  system  (using  the  Z8002  microprocessor)  from 


Advanced  Micro  Devices  (AMD) .  The  Z8002  system  contains  a 
non-seqmented  CPU  card,  a  multi-port  serial  I/O  card,  128K 
of  main  memory,  a  floppy  disk  controller,  a  clock/timer 
card,  and  a  mainframe.  This  is  the  initial  hardware  that 
is  present  in  the  lab  (Room  67,  Building  640)  .  More 
details  on  the  Z8002  is  contained  in  Appendix  A. 

Thesis  Outline 

The  rest  of  the  chapters  will  cover  the  following 
subjects : 

1.  Requirements  for  AMOS 

2.  Design  of  AMOS 

3.  Design  and  Implementation  of  AMOS  Memory  Manager 

4.  Specifications  of  Secondary  Memory 

5.  Implementation  of  AMOS 

6.  Conclusion  and  Recommendations 

Requirements  for  AMOS,  Design  of  AMOS,  and 
Implementation  of  AMOS  are  duplicated  in  Lt.  Paul  E. 
Cruser's  thesis  document.  All  of  the  appendices  are  also 
duplicated. 


I I .  Requirements 


Introduction 


The  development  cycle  of  a  software  project  begins 
with  the  requirements  analysis  (Ref  9:198).  The  broad 
requirements  for  this  project's  operating  system  can  be 
stated  in  one  sentence.  The  operating  system  is  to  be  a 
multiprogramming  operating  system  for  a  sixteen-bit 
microprocessor  computer  system  that  is  easily  changed  and 
is  machine  dependent  only  at  the  lowest  levels.  The  next 
phases  (Ref.  9:  199)  of  the  software  development  cycle 

are: 

1.  Specifications/Requirements 

2.  Design 

a.  Structural  design 

b.  Detailed  design  (algorithms) 

3.  Implementation/Coding 

4.  Testing 

5.  Operation/Maintenance 


The  steps  are  shown  graphically  in  Figure  II-l  (Ref. 
11:  13).  Although  the  testing  is  listed  as  the  fourth 
phase,  it  should  be  done  throughout  the  development  cycle. 


Figure  II-l  Software  Life  Cycle-Waterfall 
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In  this  chapter,  the  requirements  for  this  project's 
operating  system  will  be  explained  with  most  of  the 
specifications  included.  The  requirements  phase  defines  an 


acceptable  solution  to  the  problem.  During  the 
requirements  phase,  the  designer  must  understand  exactly 
what  the  user  desires  from  the  system.  If  the 
requirements  are  incorrect  and  an  error  is  not  detected 
until  later  in  the  design  phase  or  coding  phase,  then  the 
correction  of  the  error  can  take  more  time  and  effort. 
This  is  why  the  requirements  phase  is  one  of  the  most 
valuable  of  the  developmental  phases  of  any  software 
project,  although  all  of  them  need  to  work  together  to 
produce  the  end  result. 

Local  Requirements 

Other  than  fulfilling  the  requirements  for  some 
students'  project,  this  operating  system  can  be  used  in 
various  ways.  It  could  be  used  to  teach  courses  in  the 
areas  of  software  engineering,  operating  systems,  computer 
architecture,  and  computer  languages.  This  operating 
system  could  be  used  on  different  computers  for  different 
courses  and  could  possibly  provide  more  computer  services 
that  would  be  less  costly  than  an  additional  minicomputer 
(for  example,  the  VAX  11/780  on  the  first  floor  of 
Building  640).  Of  course,  this  would  be  conditional  on 


keeping  the  cost  of  the  computer  system  under  $10,000 
(Ref.  5:  11). 


Air  Force  Requirements 

As  was  stated  (Ref.  Is  10),  the  Microcomputer 
Technology  Branch  of  the  Air  Force  Data  Systems  Design 
Center  at  Gunter  AFB,  Alabama  was  created  to  supervise  the 
production  and  acquisition  of  microcomputer  software. 
This  project  can  be  used  to  serve  two  beneficial  roles: 
1)  it  can  give  insight  to  Air  Force  Acquisition  personnel 
to  correctly  specify  the  required  software  for 
microcomputers  (Ref.  Is  10)  and  2)  it  can  provide  a  fully 
documented  operating  system  that  can  be  developed  into  a 
useful  tool  which  the  Air  Force,  as  well  as  AFIT,  would  be 
able  to  utilize.  This  documentation  consists  of  structure 
charts,  process  definitions,  data  flows,  source  code 
comments,  and  a  users'  guide  which  are  located  in 
Appendices  B,  C,  D,  E,  and  F  respectively. 

Capabilities 

The  required  capabilities  for  the  operating  system 
have  already  been  developed  (Ref.  1,  4,  5).  They  are  used 
as  the  end  goals  for  the  completed  and  running  operating 
system  and  are  listed  as  follows: 
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1.  Multiuser  Support 

2.  "Friendly"  User  Interface 

3.  Communications  between  Users 

4.  Resource  Management  System 

5.  Meaningful  Error  Diagnostics 
and  Recovery  Procedures 

6.  Device  and  User  Support 

These  required  capabilities  are  also  considered  as 
the  basic  requirements  for  the  design  of  the  operating 
system.  Each  of  these  will  be  explained  in  the  rest  of 
this  chapter. 

Multiuser  Support 

One  of  the  specifications  that  are  given  for  this 
operating  system  is  that  it  is  to  be  multiprogramming. 
The  definition  given  by  Madnick  and  Donovan  (Ref.  7)  is  "a 
term  given  to  a  system  that  may  have  several  processes  in 
'states  of  execution'  at  the  same  time  (a  process  can  be 
in  a  state  of  execution  and  not  be  executing;  that  is, 


some  intermediate  results  have  been  computed  but  the 
processor  is  not  currently  working  on  the  process)"  (Ref. 


Multiprogramming  is  used  in  an  environment  that  will 
handle  concurrent  users  (as  does  the  VAX  11/780  that  was 
mentioned  earlier) .  The  first  required  capability, 
multiuser  support,  will  require  the  design  of  a 
multiprogramming  environment  for  the  operating  system. 

For  this  operating  system,  the  support  of  a  minimum 
of  four  users  has  been  given  as  the  multiuser  requirement 
for  the  implementation.  The  maximum  number  of  concurrent 
users  that  can  use  the  system  will  depend  on  three 
hardware  constraints:  1)  the  number  of  serial  and 
parallel  I/O  ports  that  can  be  used  for  Cathode-Ray  Tube 
consoles  (CRTs) ,  2)  the  memory  constraints  that  are  built 
into  the  operating  system's  data  base,  and  3)  the  size  of 
main  memory  that  is  allotted  for  the  users. 

The  design  of  the  operating  system  will  be  for  a 
multiuser  environment  of  approximately  eight  concurrent 
users.  The  initial  coding  and  implementation  will  be  for 
four  concurrent  users  and  will  be  easily  upgradable  to 
five,  and  up  to  the  maximum  of  eight,  users.  The 
upgrading  process  will  be  discussed  in  detail  later.  The 
initial  implementation  of  four  Users  will  be  an  adequate 
test  bed  for  the  multiprogramming  requirement  by  providing 
various  CPU  and  I/O  bound  processes  which  would  test  out 
the  software  (Ref.  5:  11). 


User  Interface 


The  user  interface  has  become  an  important  aspect  of 
any  operating  system.  It  is  essential  to  provide  a 
"friendly"  user  interface  which  can  be  utilized  by  users 
with  differing  computer  skills  and  backgrounds.  The  user 
should  be  able  to  easily  learn  how  to  operate  the  system. 
The  "friendly"  user  interface  of  any  operating  system  is 
characterized  by  three  qualities:  1)  ease  of  use  2) 
tolerance  of  user  errors  and  3)  minimization  of  user  error 
opportunities  (Ref.  6:  270-273).  The  operating  system 
will  work  efficiently  with  an  experienced  user  and  still 
be  able  to  assist  a  novice  user  in  learning  how  to  operate 
the  system  (Ref  5:12).  Documentation  for  the  user  will 
greatly  help  facilitate  the  learning  process. 

Inter-User  Communication 

The  inter-user  communications  of  the  operating  system 
can  be  done  using  a  mail  routine,  public  files,  or  both. 
With  a  mail  routine,  one  user  would  be  able  to  set  up  a 
file  to  send  to  another  user,  while  setting  a  mail  flag 
informing  the  second  user  of  mail.  By  using  a  public  file 
system,  any  user  can  declare  a  file  as  public  so  that 
anyone  can  read,  link,  or  list  that  file.  The  one 
restriction  for  this  method  is  no  alteration  (erase, 


overwrite,  etc.)  could  be  done  to  a  public  file,  except  by 
the  original  user.  These  two,  mail  routine  and  public 
files,  can  be  combined  in  the  system.  The  mail  routine 
can  be  used  exclusively  for  messages,  and  the  public  file 
system  can  be  used  for  program  files. 

The  mail  routine  and  the  public  file  system  are 
solutions  for  the  design.  The  requirements  for  the 
system's  inter-user  communications  would  be  met  by  using 
one  or  both  of  them. 


Memory  and  File  Manacrement 


Memory  and  file  management  is  concerned  with  four 
basic  functions  (Ref.  7:105)  : 


Keeping  track  of  the  status  of  each  location  of 
main  memory. 

Determining  a  policy  for  memory  allocation. 
Allocation  technique. 

Deallocation  technique. 


The  status  of  each  location  of  primary  memory  will  be 
either  allocated  or  unallocated.  Allocated  means  that  the 
memory  location  is  being  used  for  a  job.  Unallocated 
means  that  the  space  is  free  for  any  incoming  jobs. 
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The  policies  for  memory  allocation  will  be  influenced 
greatly  by  the  following  three  constraints:  1)  the 
maximum  number  of  jobs  allowed  on  the  system  at  a  time, 
2)  the  desired  turn-around  time  for  average  jobs  (e.g. 
shared  program  modules)  ,  and  3)  the  size  of  jobs  versus 
the  size  of  main  memory  {i.e.  can  all  jobs  fit  into  the 
allotted  working  area) .  A  few  examples  of  memory 
allocation  policies  are  partitioned  memory,  paged  memory, 
demand-paged  memory,  and  segmented  memory  (Ref.  7:  106). 
The  latter  two  provide  a  virtual  memory  feature  that  will 
be  discussed  later. 

Allocation  and  deallocation  techniques  depend  upon 
tb«  policy  selected  for  memory  management.  If  paged 
memory  management  is  selected  the  allocation  technique 
will  have  to  place  the  entire  job  into  main  memory  into  a 
series  of  blocks.  When  the  job  is  completed  the  job  needs 
to  be  removed  from  main  memory  and  the  former  allocated 
area  will  be  returned  into  free.  The  programs  that  are 
active  in  memory  need  to  have  protection,  which  is 
accomplished  by  the  allocation  technique. 

Error  Handling  and  Recovery 

The  operating  system  should  have  the  ability  to 
handle  and  recover  from  system  and  user  errors.  Not  only 
should  it  handle  and  recover  from  the  errors,  it  should 
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also  provide  informative  diagnostics  that  would  help  the 
user  better  understand  the  error.  There  are  two  types  of 
user  programming  errors:  fatal  and  non-fatal.  These  two 
types  of  user  programming  errors  can  be  handled  by 
displaying  error  messages  (the  diagnostics)  and  returning 
to  the  operating  system's  control.  The  user  could  also 
have  format  errors  with  the  command  language.  This  would 
simply  be  handled  by  giving  the  user  the  correct  format 
for  that  particular  command  as  the  diagnostics. 

The  system  can  be  modified  for  more  users,  for  a 
different  management  routine,  or  for  a  different  16-bit 
microprocessor.  There  should  be  error  detection 
capabilities  for  each  of  the  new  system  modifications. 
This  type  of  error  detection  would  be  useful  for  the 
person (s)  trying  to  complete  the  modification. 


Device  Support 


The  device 

support  will  be 

handled 

by 

the 

Input/Output  (I/O) 

Manager.  These 

devices 

can 

be 

described  as  "the  computer  system's  means  of  communicating 
with  the  world  outside  of  primary  memory.  This 
communication  may  be  with  humans  external  to  the  computer 
system  or  with  other  parts  of  the  system  (such  as  tapes, 
computer  cards,  or  disks)  not  directly  accessible  by  most 
of  the  instructions  of  the  central  processor"  (Ref.  10: 
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169).  The  four  requirements  for  the  I/O  Manager  (Ref.  5: 
15)  are  the  following: 

1.  Information  transferral  between  users  and  I/O 
devices 

2.  Conversion  of  the  user's  view  of  I/O  device 
(virtual  I/O)  to  physical  characteristics 

3.  Sharing  of  I/O  drivers 

4.  I/O  device  error  recovery 

There  are  three  major  techniques  used  for  managing  and 
allocating  I/O  devices:  1)  dedicated,  2)  shared,  and  3) 
virtual  (Ref.  7:  284).  The  third  requirement  would  be 

implemented  using  a  shared  devices  technique  and  a  virtual 
devices  technique.  The  shared  devices  technique  would 
allow  such  devices  as  disks,  drums,  and  most  other  Direct 
Access  Storage  Device  (DASD)  to  be  shared  concurrently  by 
several  processes  (Ref.  5:  284).  Slow  I/O  devices  (such 
as  teletypes,  printers,  and  card  readers)  would  have  to 
use  the  virtual  device  technique  (for  example,  a  SPOOLing 
routine)  in  order  to  convert  them  into  shared  devices 


(Ref.  5:  285). 


Design  Approach 

As  stated  in  the  first  chapter,  the  top-down  approach 
will  be  used  for  the  most  part  in  designing  of  the 
operating  system.  The  break  from  the  top-down  methodology 
will  be  when  an  algorithm  that  is  used  in  a  lower  level 
can  be  designed  and  written  before  that  level  has  been 
reached. 


Implementing  Language 


In  the  past,  operating  systems  were  written 

exclusively  in  assembly  language  (Ref.  8).  The  two  main 

reasons  are:  1)  a  well  written  and  optimized  assembly  code 

is  the  fastest-executing  code  available  and  2)  the  code 

produced  using  assembly  code  is  the  most  compact,  taking 

» 

up  the  least  amount  of  memory  (Ref.  1:  13) .  With  the  cost 
of  memory  going  down,  the  second  reason  is  not  as 
critical,  since  more  memory  can  be  purchased.  With  the 
use  of  structured  designing  (such  as  the  top-down 
approach) ,  the  use  of  structured  languages  can  be  written 
to  follow  the  physical  form  of  the  design  used. 

In  the  design  of  the  operating  system,  the  use  of  a 
high-level  structured  language  will  be  used  for  the 
control  structures,  and  the  assembly  language  of  the 
microprocessor  will  be  used  in  those  areas  where 
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performance  needs  to  be  optimal  (such  as  the  device 
drivers) .  Two  examples  that  have  used  this  type  of  hybrid 
design  are:  1)  UNIX,  written  in  the  C  language  and  2)  UCSD 
Pascal,  written  in  Pascal  (Ref.  1:  14). 

One  of  the  specifications  for  this  project's 
operating  system  is  portability.  Since  the  bulk  of  the 
operating  system  will  be  written  in  the  C  language,  it  can 
be  transferred  and  compiled  easily.  The  assembly  language 
routines  will  need  to  be  rewritten  in  the  new 
microprocessor's  assembly  language. 

As  stated  in  the  first  chapter,  the  C  language  was 
chosen  as  the  high-level  language  that  would  be  used  in 
the  final  implementation,  with  the  assembly  language  used 
for  some  of  the  machine  dependent  routines  that  cannot  be 
handled  efficiently  using  the  C  language. 

The  C  language  is  readily  available  at  AFIT.  A 
cross-compiler  from  C  to  Z8000  assembly  code  is  available 
on  the  VAX  11/780  located  in  the  Digital  Engineering  Lab. 
A  C  compiler  for  the  AMD  Z8000  processor  is  being  acquired 
from  AMD.  When  this  compiler  is  received,  it  will  be  used 
to  compile  the  C  portion  of  the  operating  system.  A 
Pascal  compiler  is  available  but  C  was  chosen  because  it 
is  less  restrictive  (Ref  1:  15). 
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Microprocessor  Consideration 

The  AMD  Z8000  microprocessor  was  selected  from  an 
extensive  study  with  three  other  16-bit  microprocessors 
(Intel  8086 /  Motorolla  68000,  and  DEC  LSI-11/23).  The 
LSI-11/23  was  not  considered  for  this  project  as  a  target 
device  (Ref  1:16). 

The  amount  of  hardware  support  offered  by  the 
microprocessor  was  important  in  the  selection  of  the 
target  device.  The  following  are  the  desired  hardware 
supports  that  the  Z8000  offers  (Ref  1:17): 

1.  Restriction  of  CPU  access. 

2.  Restriction  of  memory  access. 

3.  Memory  mapping  and  program  relocation. 

4.  Sharing  of  memory. 

5.  Context  switching  support. 

6.  I/O  interrupt  support. 

For  CPU  access  restriction  the  Z8000  was  the  only  one 
to  differentiate  between  normal  and  system  modes  with 
restriction  of  the  use  of  I/O  instructions,  control 
registers  manipulation,  and  the  HALT  instruction.  All  the 
microprocessors  require  external  circuitry  to  control 
access  to  memory,  but  the  Z8000  provides  instructions  for 
use  with  the  memory  segmentation.  When  an  interrupt  is 
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received,  the  Z8000  has  block  move  instructions  for 
facilitating  the  storage  of  the  entire  instruction  set, 
while  the  other  microprocessors  only  store  part  of  the 
machine  state.  The  Z8000  allows  the  interrupt  vector 
table  to  be  located  anywhere  in  memory,  but  all  the 
microprocessors  react  in  the  same  way  to  interrupts  (Ref 
Is  21). 

Summary 

The  implementing  language  and  the  microprocessor  were 
not  requirements  for  the  operating  system.  These  two  have 
been  presented  because  they  were  previously  selected  for 
initial  implementation  (Ref.  1) . 

For  any  system  to  be  designed  correctly,  the  designer 
must  completely  understand  what  the  user  desires  from  the 
system.  A  successful  completion  of  the  requirement  phase 
will  enable  the  designer  to  provide  the  user  with  the 
necessary  results.  Since  the  operating  system  is  a 
complex  piece  of  software,  the  requirement  phase  is  more 
important  than  in  less  complex  pieces  of  software.  This 
chapter  presented  the  requirements  for  AMOS  that  were 
defined  in  previous  thesis  efforts. 


The  C  programming  language  was  previously  selected 
(Ref  1:  22)  for  its  clarity,  power,  and  availability.  For 
these  same  resons  and  for  the  availability  of  UNIX  C 
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source  code,  C  was  selected  for  this  effort. 

The  AMD  Z8000  microprocessor  was  chosen  for  the 
initial  implementation.  The  Z8000  enables  the  operating 
system  to: 


1.  Easily  handle  main  memory. 

2.  Differentiate  between  system  and  user  tasks. 

3.  Efficiently  handle  interrupts. 


The  testing  requirements  for  AMOS  are  module  testing, 
system  testing,  and  acceptance  testing.  Module  testing 
includes  the  testing  both  the  structure  of  individual 
modules  and  the  integration  between  modules.  System 
testing  is  the  validation  of  the  system  to  it's  initial 
objectives  (Ref.  25:  232).  Acceptance  testing  is  the 
validation  of  the  system  to  it's  user  requirements  (Ref. 
25:  232) . 
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III.  Operating  System's  Design 


Introduction 


The  purpose  of  this  chapter  is  to  present  the 
detailed  design  of  the  AFIT  Multiprogramming  Operating 
System  (AMOS) . 

The  detailed  design  of  this  multiprogramming 
operating  system  was  done  using  a  top-down  methodology. 
When  using  a  top-down  approach,  a  well  structured  design 
is  possible.  This  top-down  design  approach  is  done  by 
making  the  upper-level  modules  call  only  lower-level 
modules.  This  will  allow  easier  modification  and 
understanding.  These  are  two  requirements  that  were 
previously  stated. 

This  operating  system  was  designed  with  a  structured 
programming  language  in  mind,  such  as  the  C  language  which 
was  selected.  By  using  a  well  known  and  widely  used 
programming  language  for  operating  systems,  a  portable 
system  is  obtained.  The  only  modules  that  would  need  to 
be  changed  would  be  the  low-level  driver  routines  that 
will  be  written  in  assembly  language.  The  need  for  this 
operating  system  to  be  portable  was  previously  stated  in 
the  requirements  chapter. 

The  tool  used  in  the  design  of  AMOS  is  the  structure 


chart.  The  structure  chart  was  chosen  because  as  the 
design  is  refined,  new  modules  are  identified  and  added  to 
the  chart  (Ref.  11:60).  The  initial  version  of  the 
structure  chart  is  derived  from  the  analysis  tool  called  a 
data  flow  diagram  (DFD)  (Ref.  11:  61).  The  initial 
structure  chart  for  AMOS  was  derived  from  the  DFDs 
presented  by  Reference  4.  The  DFDs  were  not  included  in 
this  text,  because  the  structure  charts  can  be  presented 
apart  from  the  DFDs  and  still  be  complete  in  its 
presentation  of  the  operating  systems  structure. 


Bootstrai 


After  the  computer  system  is  powered-on,  the 
operating  system  should  be  loaded  into  main  memory.  The 
operating  system  is  then  executed.  This  is  done  using  a 
bootstrap  program  (See  Figure  III-l) .  The  Bootstrap  does 
not  meet  any  requirements,  but  is  necessary  for  the 
operating  system  to  be  loaded  and  executed  in  a  disk 
environment.  Two  ways  that  the  bootstrap  program  can  be 


executed  are: 


Figure  III-l  Execute  Bootstrap  Program 


1.  The  use  of  a  low  level  function  on  the  system's 
monitor.  For  example,  on  the  TT-10  CP/M  systems  in 
the  Digital  Engineering  Lab,  the  letter  C  which  is 
entered  by  the  user,  initiates  a  monitor  function 
that  bootstraps  the  operating  system.  (Ref.  23) 

2.  The  processor  would  be  held  in  a  RESET  state 
while  the  disk  controller  independently  loads  a  small 
segment  of  code  from  the  disk.  This  code  is  the 
bootstrap  program  and  is  executed.  (Ref.  1:  28) 

Overall  System  Design 

The  system  design  was  separated  into  the  following 
three  parts: 


1.  Intialization  of  Data  Base. 

2.  Polling  and  parsing  of  the  command. 

3.  Determination  of  the  command  type. 

The  initialization  of  the  Data  Base  is  to  be 
performed  only  once  during  the  execution  of  AMOS.  The 
Data  Base  is  the  necessary  information  that  the  operating 


system 

requires 

in 

order 

to 

function 

properly. 

The 

polling 

and 

parsing 

of 

the 

command 

line 

and 

the 

determination 

of 

the 

command  is 

in  a  infinite 

loop 

(See 

Figure  III-2)  . 


Initialize  Data  Base 

The  operating  system  has  its  own  set  of  data 
structures  that  it  alone  can  access  and  control.  For 
example,  it  needs  structures  that  will  give  the  status  of 
processes  (process  control  blocks  or  PCBs) .  When  a 
computer  system  is  powered-on,  the  main  memory  is  not 
automatically  cleared  and  may  contain  unwanted  "garbage.” 
When  the  data  base  is  loaded  into  the  main  memory,  it 
needs  to  be  initially  set  to  predetermined  values  (See 
Figure  I I 1-3) .  Some  of  these  values  can  be  changed  during 
the  operation  of  the  operating  system,  while  others  can 
only  be  changed  by  in  the  source  code  of  the  operating 
system. 

Polling  and  Parsing  of  Command  Line 

After  the  operating  system  is  read  into  main  memory, 
a  polling  routine  is  then  executed  checking  the  various 
ports  for  incoming  commands.  The  polling  routine  will 
satisfy  the  user  "friendly"  environment.  When  a  command 
line  is  received,  it  is  parsed,  or  broken  apart,  into  the 
various  parameters.  For  example,  for  the  RUN  command,  the 
command  line  is  parsed  into  the  command  and  file  name. 
These  various  parameters  make  up  the  command  table.  This 
command  table  is  used  when  checking  the  validity  of 


a  requested  command  and  in  executing  the  command  (See 
Figure  III-4)  • 

Determine  Command  Type 

The  command  will  be  one  of  the  following  types: 

1.  User  log-in. 

2.  User  log-out. 

3.  Help  user. 

4.  User  commands. 

5.  Systems  commands. 

The  first  two  command  types  are  canned  routines, 
which  means  execution  of  these  are  similar  for  each 
request.  The  latter  three  can  vary  for  separate  requests 
having  different  parameters. 

The  user  is  attempted  to  be  logged-in.  If  the  user 
is  found  to  be  already  logged-on,  then  one  of  the 
remaining  four  command  types  is  performed.  If  the  command 
line  does  not  follow  the  defined  syntactical  format,  an 
error  handling  routine  is  called.  After  the  error  routine 
is  completed,  control  is  returned  to  the  main  body  of  the 
system  (See  Figure  III-5). 
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Figure  III-4  Parse  Command  Line 
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Figure  III-5  Determine  Valid  Command 

«  (  k)  is  a  connector  to  the  Build  Error  Message 

Module 


III-10 


Validating  Command 


When  determining  the  command  type,  user  log-in,  user 
log-out,  and  help  user  are  validated.  User  and  system 
commands  have  certain  parameters  that  must  be  verified 
before  execution. 

The  file  name  and  username  are  the  parameters  that 
are  verified  for  user  commands.  The  requested  file  is 
checked  to  see  if  it  is  located  in  secondary  memory  (e.g. 
disk  )  .  If  the  requested  file  is  located  in  secondary 
memory,  then  the  user  name  for  the  file  is  checked  against 
the  user's  username  to  verify  that  it  is  a  legal  owner  of 
the  file.  This  design  will  allow  for  public  domain 
filing.  Public  domain  filing  would  allow  any  file  to  be 
accessed  by  any  user  that  is  allowed  on  the  system. 

The  validation  of  system  commands  is  done  by  checking 
if  the  user  requesting  a  system  change  is  the  'Superuser'. 
The  'Superuser'  is  the  user  authorized  to  perform  system 
changes.  The  'Superuser's  username  and  password  should 
only  known  by  those  individuals  authorized  for  system 
access. 


Execution  of  Valid  Command 


This  module  will  ensure  the  use  of  a  multiprogramming 


environment.  This  is  done  by  having  the  System,  Log-in, 
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Log-out,  and  Help  commands  to  be  executed  without  waiting 
and  by  having  the  user  commands  wait  in  the  process 


queues . 

System  Command 

The  system  command  is  a  special  command  that  cannot 
be  used  by  any  user  logged  onto  the  system.  It  should 
only  be  executed  by  the  'Superuser.'  This  'Superuser'  has 
a  designated  username  and  password,  as  do  other  users. 
The  difference  between  the  'Superuser'  and  other  users  is 
the  username  for  the  'Superuser'  is  part  of  the  original 
source  code.  The  password  for  the  'Superuser'  should  only 
be  known  by  those  designated  individuals  that  will  have 
authority  over  the  computer  system.  The  password  for  the 
'Superuser'  should  be  changed  frequently  to  avoid  any 
tampering  by  individuals  that  determine  the  password  code. 

The  design  of  the  execution  of  the  system  command  is 
shown  in  Figure  1 1 1-6.  The  authority  of  the  user  is 
verified  by  checking  to  see  if  the  user  is  the 
'Superuser.'  If  the  user  is  not  the  'Superuser,'  then  a 
unauthorized  user  message  is  sent  to  the  user.  If 
validation  is  completed  and  the  user  is  authorized  to  use 
the  command,  then  the  system  is  configured  based  on  the 
command.  To  configure  the  system,  a  menu  is  sent  to  show 
the  options  the  user  has  to  choose,  along  with  a  prompt  to 


Command 

Table 


input  the  information.  When  the  required  information  is 
input  by  the  user,  the  system  changes  are  made  and  the 
system  is  configured  to  the  new  data. 

Log-in  User 

Before  the  user  can  do  anything  with  an  operating 
system  that  uses  usernames  and  passwords,  the  user  must 
log  onto  the  system.  In  the  design,  to  log-in  a  user  the 
following  steps  are  to  be  taken  (See  Figure  I I I — 7 ) ; 

1.  The  user  inputs  username  and  password  when 
prompted. 

2.  The  username  is  checked  against  the  list  of 
usernames  that  can  access  the  system.  If  it  is  not 
in  the  list,  then  the  user  is  not  logged  into  the 
system.  If  it  is  on  the  list,  the  password 
associated  with  the  username  in  the  list  is  checked 
against  the  password  input  by  the  user.  If  it  is  not 
the  same  password,  then  the  user  is  not  logged  into 
the  system. 

3.  The  user  parameters  are  initialized  to  log-in  the 
user  and  a  logged-in  message  is  sent  to  the  user. 
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Log-out  User 


An  importance  of  logging-off  of  a  system  is  the 
freeing  of  a  terminal  which  can  be  used  by  another  user. 
Logging-off  tells  the  system  that  you  do  not  need  to  do 
any  more  operations  and  are  freeing  the  allocated 
workspace,  terminal,  and  any  other  devices.  In  the  design 
of  the  execution  of  the  log-out  command,  the  user 
parameters  are  cleared  and  a  log-out  message  is  sent  to 
the  user.  The  user  parameters  are  the  structures  that 
inform  the  system  about  the  user's  current  status.  When 
the  parameters  are  cleared,  this  informs  the  system  that 
the  user  is  no  longer  logged-on.  The  user  would  have  to 
log-in  to  access  the  system,  after  the  log-out  command  is 
completed  (See  Figure  III-8) . 

Help  Command 

If  a  help  command  is  received  the  user  can  be 
requesting  either  system  information  or  command 
information.  Whichever  is  requested  the  user  is  provided 
with  the  necessary  information.  The  design  does  not 
include  the  necessary  information  for  user  log-in.  This 
information  will  be  documented  and  available  for  each 
user.  This  implies  that  a  user  must  be  logged  in  to 


request  help 


Figure  III-8  Logout  User 


In  the  design  of  the  execution  of  the  help  command, 
the  information  is  retrieved  and  sent.  Before  the 
information  is  retrieved,  the  command  is  checked  to 
determine  if  the  user  is  requesting  command  information  or 
system  information.  Command  information  is  the  format  of 
commands  and  the  description  of  what  the  commands  do. 
System  information  is  the  status  of  the  computer  system 
(See  Figure  III-9) . 

User  Commands 

User  commands  are  divided  into  the  following  five 
types: 

1.  Running  a  file. 

2.  Listing  a  file. 

3.  Printing  a  file. 

4.  Deleting  a  file. 

5.  Directory  information. 

The  execution  of  all  user  commands  are  similar. 
First  the  file  must  be  located  (the  directory  is  saved  in 
a  specific  location) ,  second  the  file  must  be  retrieved 
from  secondary  memory,  third  the  file  is  buffered  into 
main  memory,  fourth  the  job  is  placed  into  a  waiting  queue 
for  execution.  After  the  four  steps  the  files  waits  for 
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its  turn  for  execution. 

To  run  a  file,  the  executable  code  is  located  in  main 
memory  and  then  executed  for  the  user.  To  list  a  file  the 
file  is  taken  from  main  memory  and  transmitted  to  the 
user's  terminal.  Printing  a  file  is  similar  to  listing  a 
file  except  it  is  transmitted  to  a  printer.  Deletion  of  a 
file  is  done  by  buffering  in  the  directory  section 
containing  the  file  information  and  deleting  it  from  the 
listing  and  then  writing  it  back  out  to  secondary  memory. 
Directory  information  is  executed  by  transmitting  the 
buffered  directory  to  the  user's  terminal  (See  Figure 
III-10)  . 


Evaluation  of  AMOS  Design  (Testing) 


The  evaluation  of  AMOS  design  consisted  of  a  two 
phase  process.  The  first  phase  checked  to  see  if  the 
design  had  a  logical  structure.  A  logical  structure 
should  have  upper-level  modules  calling  lower-level 
modules  in  a  organized  sequence.  The  sequence  would 
follow  a  logical  flow.  For  example,  it  is  necessary  to 
call  a  module  getting  a  username  before  calling  a  module 
to  check  if  the  username  is  valid.  The  second  phase 
determined  if  the  data  flow  between  modules  was  logical. 
The  data  would  be  needed  in  the  called  module  or  in 


another  lower-level  module.  This  lower-level  module  is 
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a  child  of  the  called  module  (Ref.  13:  220). 

In  the  evaluation  of  the  logical  structure,  a  few 
minor  changes  were  necessary.  One  of  these  changes 
involved  the  polling  routine.  The  first  design  did  not 
take  into  account  that  the  users  could  be  idle  for  a  long 
period  of  time  while  a  process  was  ready  to  run.  The  call 
to  the  Process  Scheduler  was  added  after  a  set  number  of 
polls  with  no  response.  Another  change  involved  execution 
of  a  user  command.  The  execution  of  each  user  command  was 
similar;  this  allowed  for  common  modules  that  would  be 
called  to  execute  the  commands. 

The  data  flow  was  verified  to  be  logical  with  a  few 
changes.  To  execute  a  command,  in  the  initial  design,  the 
command  table  was  the  data  flow  item  passed  between  the 
modules.  When  the  Process  Scheduler  was  incorporated  into 
the  design,  the  process  control  block  was  the  new  data 
flow  item. 


Summary 


This  chapter  presented  the  overall  system  design  of 
AMOS.  The  top-down  design  approach  was  followed  using 
structure  charting.  The  operating  system  was  designed 
with  the  idea  that  it  would  be  implemented  using  a 


structured  programming  language,  i.e.  C. 


Introduction 

Memory  management  deals  with  the  management  of  main 
memory  (Ref.  7:  105).  The  memory  management  scheme 

selected  for  initial  implementation  on  AMOS  was  dynamic 
partitioned  allocation.  The  reason  this  scheme  was 
selected  over  other  possible  ones  will  be  explained  in 
this  chapter.  The  follow  are  four  basic  functions  that 
any  memory  management  technique  processes  (Ref.  7:  105). 

1.  Keeping  track  of  the  status  of  each  main  memory 
location. 

2.  A  policy  of  allocation  of  main  memory  to  jobs. 

3.  An  allocation  technique. 

4.  A  deallocation  technique. 

The  status  of  any  main  memory  location  can  be  either 
allocated  or  unallocated.  The  importance  of  this  function 
is  to  ensure  that  if  a  process  is  in  main  memory  waiting 
for  execution  can  not  be  over  written,  and  that  the  area 
of  main  memory  for  the  operating  system  is  always 
allocated.  Even  with  a  single  user  system  it  is  important 
to  the  status  of  each  memory  location. 


The  policy  for  allocation  of  main  memory  is  dependent 
on  the  type  of  system  to  be  implemented  (Ref.  7:  105,106). 
If  the  initial  implementation  requires  only  a  few  users,  a 
simple  policy  would  be  sufficient.  For  a  larger  number  of 
users,  a  very  complex  policy  would  be  necessary  for  a  more 
efficient  use  of  available  memory. 

Allocation  and  deallocation  is  the  process  of  placing 
jobs  in  and  then  taking  them  out  of  main  memory 
respectively.  The  allocation  of  main  memory  to  jobs  is 
important  to  allow  execution  and  to  allow  for  the 
execution  of  the  maximum  number  of  jobs.  Deallocation  is 
important  to  remove  jobs  as  efficiently  as  possible. 


AMOS  Memory  Allocation 


Dynamic  partitioned  allocation  (DPA)  was  the  scheme 
initially  selection  for  implementation  for  AMOS.  Because 
DPA  allows  for  multiprogramming  which  is  mandatory  for 
AMOS,  unlike  a  single  contiguous  scheme.  The  level  of 
complexity  is  not  as  great  as  a  segmentation  or 
demand-paged  allocation  schemes  (Ref.  7).  Also  by 
implementing  with  DPA  the  operating  system  can  be  easily 
updated  to  handle  different  algorithms  which  is  necessary 
for  a  teaching  system. 

The  first  criteria  that  DPA  allows  for  is  to  have 


more  than  one  job  in  main  memory  at  one  time.  This  is 


i«9 


done  by  allocating  the  amount  of  memory  that  the  job  needs 
and  no  more.  The  rest  of  the  area  that  the  job  is  not 
located  in  is  unallocated  (free) .  This  free  area  can  then 
be  used  to  load  other  jobs  into  main  memory. 

Status  of  Memory  Partition  on  AMOS 

The  status  of  each  memory  location  is  determined  by 
having  a  buffer  that  contains  the  beginning  and  ending 
address  of  each  allocated  jobs.  Any  area  of  main  memory 
not  residing  in  the  buffer  is  considered  as  'free'  area. 

Allocation  Policy  Used  on  AMOS 

The  two  type  of  allocation  policies  that  could  be 
implemented  on  AMOS  are  first-fit  and  best-fit.  First-fit 
searches  the  free  area  table  to  find  the  first  partition 
large  enough  to  fit  the  incoming  job  (Ref.  3:  250).  This 
free  area  table  is  ordered  by  memory  location.  The  first 
area  of  memory  that  can  accomodate  the  job  will  be  used 
and  the  unused  area  will  remain  free.  Best-fit  searches 
the  free  area  table  to  find  the  partition  that  wastes  the 
minimum  amount  of  space  (Ref.  3:  249).  If  the  free  area 
table  is  ordered  by  the  size  of  the  partitions,  then  the 
algorithm  used  in  best-fit  is  the  same  as  in  first-fit. 
This  is  true,  since  the  first  partition  large  enough  for 


the  incoming  job,  it  is  also  the  best  partition.  Best-fit 
also  reserves  large  partitions  for  large  jobs  by  using 
small  partitions  for  small  jobs.  Because  of  this,  it  is  a 
greater  possibility  that  large  jobs  will  be  executed 
without  any  wait  by  using  best-fit.  By  all  of  the  above 
reasons,  best-fit  was  the  policy  selected  for  initial 
implementation  on  AMOS. 

Allocation  on  AMOS 

Once  a  large  enough  partition  is  available  for  a  job 
the  process  of  allocation  is  necessay.  On  AMOS  a  job  is 
read  from  secondary  memory  a  sector  at  a  time  and  then 
transfered  into  the  appropriate  partition.  The  reamining 
area  is  placed  into  free  area  and  the  occupied  area  is 
considered  allocated.  Once  the  entire  job  is  in  main 
memory  the  beginning  and  ending  address  is  placed  into  the 
job  scheduler  waiting  queue.  There  the  job  is  waiting  to 
be  executed. 

Deallocation  on  AMOS 

After  a  job  is  completed  execution  the  area  that  it 
resides  in  must  be  made  into  free  area.  This  is  done  by 
taking  the  allocated  array  is  changed  reflecting  that  the 
job  is  removed.  This  program  will  remain  in  main  memory 
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other  job  over  writes 
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This  program  is 

unable 

to 

be  accessed  since  the 

area 

it  occupies  is 

consider  'free.' 


Design  of  AMOS's  Memory  Management 


The  design  of  AMOS's  memory  management,  like  the  rest 
of  the  operating  system,  was  done  using  a  top-down 
approach.  The  memory  management  design  was  separated  into 
the  following  two  parts: 


1.  Allocating  the  job  to  main  memory 

2.  Deallocating  the  job  from  main  memory 

Allocating  the  Job  to  Main  Memory 


The  process  Get  File  calls  the  necessary  processes 
for  placing  a  job  into  main  memory  and  preparing  the  job 
for  execution  (See  Figure  IV-1) .  The  following  are  the 
processes  that  Get  File  calls: 

1.  Check  Space 

2.  Build  PCB 

3.  Read  File 

4.  Build  Error  Message 


IV- 5 


Command 

Table 


Figure  IV-1  Get  File 


Check  Space,  determines  if  there  is  enough  main 
memory  space  for  allocation  of  the  job  and  where  in  main 
memory  the  job  is  to  be  placed.  Build  PCB,  constructs  and 
initializes  a  Process  Control  Block  that  is  necessry  for 
execution  of  the  job.  Read  File,  reads  the  job  from 
secondary  memory  and  places  it  into  main  memory  at  the 
alresdy  prescribed  location.  Build  Error  Message  is 
called  when  there  isn't  enough  available  space  for 
execution  of  the  job  and  if  the  job  is  too  large  for 
execution  on  the  system. 

Deallocating  the  Job  from  Main  Memory 

Deallocation  of  the  memory  is  executed  when  a  job  is 
completed  or  aborted.  The  module  Run  Process  calls 
Deallocate  Memory  Space  to  have  the  space  'freed,'  (See 
Figure  IV-2) .  After  this  main  memory  area  is  'freed,' 
control  is  returned  to  Run  Process.  If  there  is  a 
timeslicing  environment,  then  this  must  only  be  called 
when  the  job  is  completed  or  aborted  and  not  when  the  job 
is  stopped. 

Implementation  of  AMOS ' s  Memory  Management 

The  coding  of  AMOS's  memory  management  is  a 
one-to-one  transfer  from  the  structure  charts.  The 
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ire  IV-2  Run  Process 


IV-8 


v  .  •  •  * .  • 


pseudocodes  of  the  modules  to  be  discussed  in  this  section 


1.  Get  File 

2.  Check  Space 

3.  Read  File 

4.  Deallocate  Space 

The  source  code  of  these  subroutines  can  be  found  in 
Appendix  E. 

Get  File 

Get  File  calls  a  subroutine  called  Check  Space  which 
determines  if  there  is  enough  available  space  in  main 
memory  for  execution  of  the  job.  If  there  is  enough 
space,  the  job  is  then  located  in  secondary  memory.  The 
job  is  then  taken  from  secondary  memory  and  placed  in  main 
memory  in  a  contiguous  section.  Once  the  entire  job  is 
placed  in  main  memory  the  number  of  jobs  in  the  system  is 
incremented  by  one.  If  there  is  enough  space  for  the 
execution  of  the  job,  an  error  handling  routine  is  called 
and  control  is  returned. 

The  following  is  the  pseudocode  of  the  Get  File 


subroutine . 


Procedure  Get  File 


If  enough  space  for  job  (Check  Space) 
then 

Build  PCB 

Read  the  job  into  main  memory  (Read  File) 

Increment  number  of  jobs  in  main  memory 
End  if 
Else 

Call  error  handling  subroutine 
End  else 

End  Procedure  Get  File 

***** 

Check  Space 

Check  Space  searches  the  free  area  table  to  find  the 
a  location  where  the  incoming  job  can  be  placed.  If  there 
is  more  than  one  job  on  the  system,  a  subroutine  called 
Sort  is  called  to  order  the  free  area  table  from  smallest 
memory  location  to  largest.  Thus,  the  first  partition 
large  enough  for  the  incoming  job  is  also  the  best 
partition.  Check  Space  calls  the  error  handling  routine 
when  the  incoming  job  is  too  large  for  all  of  main  memory. 
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The  following  is  the  pseudocode  of  the  Check  Space 


subroutine . 


***** 


Procedure  Check  Space 
If  two  or  more  jobs  in  main  memory 
then 

Call  Sort  to  have  free  area  table  ordered  by  memory 
locations 
End  if 

If  large  enough  partition  for  the  job 
Allocate  the  memory  needed 
Return  enough  space  flag 
End  if 
Else 

If  program  too  large  for  all  of  main  memory 
Call  Build  Error  Message 
End  if 

Return  Not  enough  space  flag 
End  else 

End  Procedure  Check  Space 

***** 
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Read  File 


Read  File  locates  the  file  in  secondary  memory  and 
the  reads  it  into  main  memory  in  a  contiguous  block. 
While  each  byte  is  being  read  in,  it  checks  to  see  if  an 
End  of  File  (EOF)  marker  has  been  reached.  This  indicates 
that  the  entire  file  has  been  read  from  secondary  memory. 
Once  the  EOF  has  been  reached  control  is  returned  to  the 
calling  module. 

The  following  is  the  pseudocode  for  the  Read  File 
subroutine , 


Procedure  Read  File 
While  not  EOF 

Read  a  block  of  the  file  and  place  into  main  memory 
Check  for  end  of  file  marker 
Move  to  next  block 
End  while 

End  Procedure  Read  File 


Deallocate  Space 


Deallocate  Space  'frees'  tnat  area  of  main  memory 
where  a  completed  or  aborted  job  was.  This  is  done  by 
just  updating  the  free  area  table  to  indicate  the  area  is 
now  'free.'  The  jobs  in  main  memory  must  also  be 
decremented  by  one 

The  following  is  the  pseudocode  for  the  Deallocate 
Space  subroutine. 

***** 
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Procedure  Deallocate  Space 
Determine  which  area  is  to  be  'freed' 

Remove  that  area  from  the  free  area  table 
Decrement  the  number  of  jobs  in  main  memory 
End  Procedure  Deallocate  Space 


***** 

Summary 

Dynamic  partitioned  allocation  with  a  best-fit  policy 
was  the  memory  management  scheme  selected  for  initial 
implementation  on  AMOS.  The  design  of  the  memory 
management  part  of  AMOS  was  separated  into  two  parts. 
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These  two  parts  were  allocating  the  job  to  main  memory, 
and  deallocating  the  job  from  main  memory.  The  pseudocode 
for  the  memory  management  subroutines  was  presented  in 
this  chapeter.  The  actual  source  code  of  these 
subroutines  can  be  found  in  Appendix  E. 


The  purpose  of  this  chapter  is  to  present  the 
specifications  for  secondary  memory.  The  specifications 
for  secondary  memory  are: 

1.  Directory  format 

2.  Sector  format 

Directory  Format 

The  directory  is  divided  into  two  areas.  These  areas 
are  the  free  sector  information  and  the  file  information. 
The  free  sector  information  is  located  in  the  first  six 
bytes  of  the  directory.  The  file  information  follows  the 
free  sector  information  in  groups  of  27  bytes.  The 
following  is  a  byte  description  of  the  directory: 


Figure  V-l  Directory  Byte  Description 


The  first  two  bytes  of  the  directory  contain  the 
value  for  the  number  of  free  sectors  on  the  disk.  The 


next  two  bytes  point  to  the  track  and  the  sector  of  the 
first  free  sector.  The  last  two  bytes  point  to  the  track 
and  sector  of  the  last  free  sector. 

The  file  information  group  is  divided  into  the 
following  four  blocks: 


1.  File  status  (1  byte) 

2.  Filename  (12  bytes) 

3.  Username  (8  bytes) 

4.  File  Information  (6  bytes) 


The  following  is  a  byte  description  of  each  directory 
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Figure  V-2  Directory  Entry  Byte  Description 


The  status  of  a  file  is  either  accessable  or  deleted. 
If  a  file  is  accessable,  byte  0  has  the  null  character. 
If  a  file  has  been  deleted,  byte  0  has  the  asterisk  ("*") 
character.  It  is  necessary  to  update  this  byte  whenever  a 
file  is  added  to  or  deleted  from  the  disk.  If  a  file  is 
added,  the  sectors  that  the  file  was  placed  in  must  be 
removed  from  the  free  area.  If  a  file  is  deleted  the 
sectors  that  the  file  was  in  must  be  added  to  the  free 
area. 

Bytes  1-12  contains  the  name  of  the  file  with  its 
extension.  The  first  8  bytes  is  the  file's  name.  Byte  9 
has  the  period  character.  Bytes  10-12  contains  the 
extension  of  the  file. 

Bytes  13-20  contains  the  username  of  the  user  who 
saved  the  file  on  disk.  This  allows  for  the  file  to  be 
accessable  only  to  the  user  who  saved  the  file.  This  also 
allows  for  a  type  of  mail  routine  by  having  a  reserved 
username  of  any  public  file. 

Bytes  21-26  contains  the  files  size  and  location 
information.  The  first  two  bytes  contain  the  number  of 
sectors  that  the  file  occupies.  The  next  two  bytes  are 
the  beginning  track  and  sector  of  the  file.  The  last  two 
bytes  are  the  ending  track  and  sector  of  the  file. 


Sector  Format 

A  typical  8  inch  single  density  floppy  disk  contains 
128  bytes  per  sector.  The  format  of  each  sector  of  AMOS’s 
secondary  memory  will  consist  of  the  last  two  bytes 
pointing  to  the  next  track  and  sector  in  its  respective 
list.  The  byte  description  of  each  sector  is  shown  in 
Figure  V-3.  These  lists  are  the  free  sector  list  and  the 
file  sector  list.  The  last  sector  of  each  list  points  to 
track  0,  sector  0.  This  indicates  that  the  end  of  the 
free  area  or  file  has  been  reached. 

When  a  disk  is  formatted  for  AMOS,  a  directory  entry 
is  reserved,  then  each  remaining  sector  points  to  the  next 
logical  sector  with  the  last  sector  pointing  to  track  0, 
sector  0.  The  logical  sector  is  determined  by  the 
rotation  speed  of  the  floppy  and  the  retrieval  time  of  the 
floppy  (Ref.  7:  303-306).  The  directory's  first  6  bytes 
contain  the  number  of  free  sectors  and  the  locations  of 
the  first  and  last  free  sectors. 
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Figure  V-3  Sector  Byte  Description 
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When  a  file  is  added  to  secondary  memory,  the  file  is 
stored  at  the  first  free  sector  and  is  then  stored  in  each 


successive  logical  sector  until  the  end  of  the  file  is 
reached.  The  last  sector  points  to  track  0  and  sector  0. 
The  free  area  table  and  directory  is  the  updated  to 
indicate  the  change.  When  a  file  is  deleted  from 
secondary  memory  the  last  sector  of  the  free  area  table 
points  to  the  first  sector  of  the  file.  The  free  area 
table  and  directory  must  be  updated  to  indicate  the 
change. 

Summary 

This  chapter  presented  the  specifications  of 
secondary  memory  storage.  These  specifications  included 
directory  and  sector  format  that  the  main  memory  manager 
requires.  The  secondary  memory  manager  was  not 
implemented  because  of  the  lack  of  driver  routines. 
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Introduction 


The  purpose  of  this  chapter  is  to  present  the 
pseudocode  of  the  algorithms  that  were  chosen  for 
implementation  in  the  detailed  design.  The  coding  of  the 
operating  system,  and  some  of  the  problems  that  occurred, 
are  also  discussed. 

"Coding  is  the  implementation  of  the  refined  design, 
with  the  idiosyncracies  of  the  programming  language, 
operating  system  environment,  and  external  (human  and 
hardware)  interfaces  taken  into  account"  (Ref.  11:  12). 

Since  the  structure  charts  were  used  in  the  detailed 
analysis,  the  coding  was  nearly  a  one-to-one  transfer 
from  structure  chart  module  to  coded  subroutines.  This 
provided  the  modularity  that  was  striven  for  in  the 
design.  The  updating  of  any  of  the  subroutines,  either 
making  a  minor  change  in  the  original  subroutine  or 
replacing  the  entire  subroutine,  can  be  done  without 
changing  any  other  routines,  as  long  as  the  interfaces 
between  subroutines  do  not  change. 


The  Main  subroutine  is  the  first  procedure  that  is 


executed.  This  subroutine  was  coded  using  the  design 
given  for  the  EXECUTE  AMOS  module  in  Figure  I I 1-2  on  page 
III-5.  The  operating  system  is  centralized  around  this 
subroutine.  The  following  is  the  pseudocode  for  the  Main 
subroutine : 


***** 


Procedure  Main 
Initialize  Data  Base 
Loop 

Parse  the  command  line 
Determine  valid  command 
Forever 

End  Procedure  Main 

***** 


Initialize  Data  Base 

The  Data  Base  is  information  used  by  the  operating 
system  and  is  defined  in  the  source  code.  Since  the 
passing  of  variable  parameters  is  complex,  the  C-defined 


structures  for  the  Data  Base  are  global  to  the  operating 


system.  The  variables  are  made  global  by  defining  them 


before  the  main  module  (Ref.  12). 


The  implementation  of  initializing  the  Data  Base  is 


done  by  using  a  simple  operator,  the  assignment  or  '=.' 


This  subroutine  was  coded  using  the  design  given  in  Figure 


III-3,  on  page  III-7.  The  information  that  will  remain 


constant  during  the  execution  of  the  operating  system  is 


implemented  using  the  C  language  'idefine'  (Ref.  12:  86). 


The  information  that  might  be  changed  during  the  execution 


of  the  operating  system  is  initialized  in  a  subroutine, 


called  INITIALIZE-DATA-BASE  (see  Appendix  E) .  The  initial 


values  can  only  be  changed  by  software  enhancement.  This 


implementation  is  only  recommended  for  the  initial 


testing.  Any  updated  version  of  INITIALIZE  DATA  BASE 


module  should  follow  the  design  presented  in  figure  III-3, 


on  page  I I 1-7. 


The  suggested  implementation  for  initializing  the 


Data  Base  is  reading  the  information  from  a  file  on  the 


operating  system's  disk  (e.g.  the  VMS  0/S  for  the  VAX 


11/780  located  in  the  Digital  Engineering  Lab  (Ref.  DEL)  ) 


This  allows  for  an  easy  updating  of  the  Data  Base.  For 


example,  when  adding  another  terminal  to  the  computer 


system,  it  is  not  necessary  to  change  the  source  code  and 


recompile  it.  The  changes  can  be  done  by  a  System  command 


which  can  be  written  when  this  implementation  is  added. 
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The  System  command  would  change  the  information  in  the 
following  parameters: 

1.  noports,  the  number  of  on-line  terminal  ports. 

2.  MAXJOBS ,  the  maximum  number  allowed  on  the 
system. 

3.  portdata,  the  data  table  for  the  terminal 
ports . 

The  changes  in  the  Data  Base  would  be  saved  in  the 
Data  Base  file  either  when  the  System  command  to  change 
the  Data  Base  is  executed  or  when  the  operating  system  is 
shut  down.  The  shutting  down  of  the  operating  system 
would  be  performed  by  another  System  command  that  would 
also  be  written  when  this  implementation  is  added.  This 
System  command  is  not  needed  for  the  initial 
implementation  because  the  saving  of  the  Data  Base  is  not 
essential.  The  reason  for  this  is  the  Data  Base 
initialization  is  coded.  It  is  recommended  that  the  Data 
Base  be  saved  at  the  time  it  is  changed  and  at  the  time  a 
system  shut  down  is  performed.  This  will  ensure  that  the 
information  of  the  Data  Base  is  saved  if  a  power  failure 
occurs  after  a  change. 
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Parse  Command  Line 


This  subroutine  waits  for  a  user  to  attempt  to 
communicate  with  the  operating  system,  gets  the  user's 
command  line,  and  parses  the  line.  The  command  line  is 
the  character  string  that  the  user  inputs  from  the 
terminal  and  is  terminated  by  a  carriage  return.  This 
subroutine  was  coded  using  the  design  given  for  the 
PARSE  COMMAND  LINE  module  in  Figure  1 1 1-4,  on  page  1 1 1-9. 
The  following  is  the  pseudocode  for  the  Parse  Command  Line 
subroutine : 


***** 


Procedure  Parse  Command  Line 
If  Poll  is  true 
then 

Get  the  command  line 

Build  the  command  table  (parse  the  command  line) 
End  if 


End  Procedure  Parse  Command  Line 


The  Poll  subroutine  returns  a  boolean  value  (true  or 
false) .  It  polls  the  terminal  ports  to  determine  if  there 
is  any  input.  The  polling  algorithm  used  is  circular, 
that  is,  it  starts  from  the  beginning  of  the  ports  (port 
0)  ,  goes  through  to  the  ending  of  the  ports  (port  n-1, 
where  n  is  the  number  of  terminals  on  line) ,  and  goes  back 
to  the  beginning  of  the  ports.  It  checks  those  ports  that 
do  not  have  a  submitted  job.  If  a  response  is  found,  the 
polling  routine  is  stopped  and  the  true  is  returned  to  the 
Parse  Command  Line  subroutine.  If  it  goes  through  one 
pass  of  the  ports  and  does  not  receive  a  response,  then  it 
calls  the  Process  Scheduler.  The  Process  Scheduler  takes 
care  of  the  processes  that  are  submitted.  This  ensures 
that  any  process  that  is  in  any  of  the  process  queues  has 
the  chance  to  run.  After  returning  from  the  Process 
Scheduler,  the  polling  is  resumed.  The  following  is  the 
pseudocode  for  the  Poll  subroutine: 


1 


Procedure  Poll 
Set  i  to  0 
While  no  response 
While  not  one  pass  and  no  response 
If  no  process  submitted  from  port[i] 
then 

Check  port[i]  for  response 
If  response 
then 

Return  true 
End  if 
End  if 

Set  i  to  next  port  number 
End  while 
If  no  response 
then 

Process  Scheduler 
End  while 
End  Procedure  Poll 


Determine  Valid  Command 

The  subroutine  Determine  Valid  Command  determines 
what  type  the  command  is  (i.e.  system,  user,  help,  and 
control) .  If  that  particular  command  is  valid,  then  it 
calls  the  necessary  routines  to  have  the  command  executed. 
This  subroutine  was  coded  using  the  design  given  for 
the  DETERMINE  VALID  COMMAND  module  in  Figure  1 1 1-5,  on 
page  III-10.  The  following  is  the  pseudocode  for 
Determine  Valid  Command: 

★  ★  ★  *  ★ 


Procedure  Determine  Valid  Command 
If  user  already  logged  in 
then 

If  Log  out  command 
then 

Log  Out  User 
End  If 

If  Help  command 
then 

Help  User 
End  if 


If  System  command 


System  Change 


End  if 

If  User  command 
then 

Execute  User  Command 
End  if 

If  invalid  command 
then 

Send  invalid  command  message 
End  if 
End  if 

End  Procedure  Determine  Valid  Command 

★  ★  *  *  * 

Log  In  User 

The  procedure  Log  In  User  accomplishes  one  or  two 
functions.  If  a  user  inputs  a  command  line,  then 
Determine  Valid  Command  wants  to  know  if  the  user  is 
already  logged  on.  If  the  user  is  logged  on,  then  control 
returns  to  Determine  Valid  Command  to  execute  the  user's 
command,  else  the  user  is  attempted  to  be  logged  on.  The 
global  table  userblock  has  a  logged  on  flag  that  is  set  to 
true  or  false.  The  flag  that  corresponds  to  the 
terminal's  port  number  is  checked  to  determine  if  the  user 


is  logged  on,  yet.  This  subroutine  was  coded  using  the 
design  given  for  the  LOG-IN  USER  module  in  Figure  III-7, 
on  page  III-15.  The  following  is  the  pseudocode  for  the 


Log  In  User  subroutine: 


***** 


Procedure  Log  In  User 
If  user  not  logged  on 
then 

Prompt  user  for  username 
Read  in  username 
Prompt  user  for  password 
Read  in  password 
If  legal  username  and  password 
then 

Copy  username  into  userblock 
Set  loggedon  flag 

Increment  number  of  users  on  system 
Send  login  completed  message  to  user 
End  if 
End  if 

End  Procedure  Log  In  User 

***** 
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Log  Out  User 

The  Log  Out  User  subroutine  is  a  simple  routine,  but 
accomplishes  an  important  cleanup  function.  It  clears  the 
userblock  of  the  username  and  sets  the  logged  on  flag  to 
false.  It  also  sets  the  jobrunning  flag  to  false.  The 
jobrunning  flag  should  already  be  false,  since  the  user 
cannot  communicate  with  the  operating  system  unless  no 
jobs  were  running.  This  subroutine  was  coded  using  the 
desgn  given  for  the  LOG-OUT  USER  module  in  Figure  I I 1-8, 
on  page  1 11-17.  The  following  is  the  pseudocode  for  the 
Log  Out  User  subroutine: 

★  ★  ★  ★  * 

Procedure  Log  Out  User 
Send  logged  out  message  to  user 
Clear  username  space  in  userblock  table 
Set  loggedon  and  jobrunning  to  false 
Decrement  number  of  users  on  system 
End  Procedure  Log  Out  User 

***** 
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The  Help  User  subroutine  provides  information  to  the 
requesting  user.  The  two  types  of  information  that  is 
provided  are  system  information  and  command  information 
(Ref.  4:  52).  A  system  help  request  would  give 
information  to  the  user  about  the  system.  The  following 
is  an  example  of  a  system  help  request: 


'HELP  USERS' 


This  command  line  would  result  in  the  listing  of  all 
of  the  users  that  are  logged  into  the  system  and  what 
terminal  number  that  each  user  is  using.  A  command  help 
request  would  give  the  format  for  the  command  and  any 
information  for  the  command. 

The  following  is  an  example  of  a  command  help 
request: 


'HELP  DEL’ 


The  response  from  the  operating  system  would  be 
follows : 


'Format:  DEL  FILENAME' 
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This  subroutine  was  coded  using  the  design  given  for 
the  HELP  USER  module  for  in  Figure  III-9,  on  page  III-19. 
The  following  is  the  pseudocode  for  the  Help  User 
subroutine : 

***** 

Procedure  Help  User 
If  system  information  is  requested 
then 

Determine  what  information  is  requested 
Get  the  information  and  send  to  the  user 
End  if 
Else 

If  command  information  is  requested 
then 

Determine  which  command's  information  is  needed 
Send  the  format  and  other  information 
End  if 
Else 

Send  no  help  available  message 
End  else 
End  else 

End  Procedure  Help  User 


it  it  it  It  it 
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System  Change 

The  System  Change  subroutine  determines  that  the  user 
is  the  'Superuser',  then  it  determines  what  changes  in  the 
Data  Base  are  requested,  gives  the  user  any  needed  prompts 
for  the  new  information,  and  performs  the  necessary 
changes.  This  subroutine  was  coded  using  the  design  given 
for  the  SYSTEM  CHANGE  module  in  Figure  III-6,  on  page 
I I 1-13.  Because  the  initial  coding  of  the  operating 
system  does  not  have  a  dynamic  Data  Base  (that  is,  the 
initial  values  cannot  be  changed  from  loading  to  loading 
on  the  computer  system) ,  there  are  no  system  changes  that 
can  be  permanently  performed.  When  the  dynamic  Data  Base, 
using  a  Data  Base  file,  is  implemented,  system  changes  can 
be  performed  with  the  changes  saved. 

In  the  coding  and  design  of  this  operating  system,  a 
process  is  sent  through  the  Process  Scheduler  to  be 
executed.  But  the  system  command  is  an  exception,  it  is 
executed  without  having  to  go  through  the  Process 
Scheduler  to  run.  The  option  to  execute  it  with  the  other 
processes  is  in  the  source  code,  because  of  the  following: 


1.  A  System  Ready  Queue  is  available. 

2.  A  Process  Control  Block  (pcb)  is  made  for  the 
system  command. 
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3. 


The  pcb  is  entered  into  the  System  Ready  Queue. 

A  subroutine  is  written  that  would  execute  the 


4. 

system  command  when  it  is  given  the  processing 
time. 

The  following  is  the  pseudocode  for  the  System  Change 
subroutine : 


Procedure  System  Change 
If  the  Superuser 
then 

Determine  which  change  is  to  be  performed 
Prompt  the  Superuser  for  the  new  information 
Get  Superuser's  response 
Change  the  Data  Base 
End  if 
Else 

Send  not  Superuser  message  to  user 
End  else 

End  Procedure  System  Change 

*  ★  *  ★  ★ 
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Execute  User  Command 


This  subroutine  determines  if  the  requested  user 
command  is  valid.  That  is  if  the  file  being  requested  is 
located  in  secondary  memory,  and  if  the  user  is  requesting 
their  file.  This  subroutine  was  coded  using  the  design 
given  for  the  EXECUTE  USER  COMMAND  module  in  Figure 
III-10,  on  page  III-21.  For  the  RUN  command  it  is  also 
necessary  to  determine  if  the  requested  file  is  an 
executable  file.  If  the  command  is  found  to  be  valid  then 
it  calls  the  necessary  routine  for  execution.  The 
following  is  the  pseudocode  for  the  Execute  User  Command 
subroutine: 

***** 

Procedure  Execute  User  Command 
If  the  command  is  valid  (Validate  User  Command) 
then 

Execute  the  valid  command  (Execute  Command) 

End  if 
Else 

Send  error  message  to  the  user 
End  else 

End  Procedure  Execute  User  Command 

***** 
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Validate  User  Command 


This  subroutine  determines  if  the  user  has  input 
valid  parameters.  If  all  the  parameters  are  valid, 
control  is  returned  to  the  calling  subroutine.  If  any 
parameter  is  invalid,  an  error  subroutine  is  called  to 
handle  the  particular  error. 

This  subroutine  was  coded  using  the  design  given  for 
the  VALIDATE  USER  COMMAND  module  in  the  figure  on  page 
B-ll.  The  following  is  the  pseudocode  for  the  Validate 
User  Command  subroutine: 


*  *  *  *  * 


Procedure  Validate  User  Command 
If  RUN  command 
then 

Check  filename,  username,  and  if  executable  file 
End  if 

If  LIST,  PRINT,  or  DEL  command 
then 

Check  filename,  check  username 
End  if 

If  DIR  command 
then 
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This  command  is  always  valid 
End  if 

End  Procedure  Validate  User  Command 

***** 

Execute  Command 

This  subroutine  calls  the  necessary  subroutine  to 
move  a  job  from  secondary  memory  into  main  memory.  The 
steps  to  perform  this  task  are: 

1.  Locating  the  file. 

2.  Getting  the  file. 

3.  Placing  the  file  into  main  memory. 

4.  Calling  the  appropriate  subroutine. 

After  these  steps  are  finished  the  Process  Scheduler 
is  called.  The  Process  Scheduler  will  then  perform  the 
appropriate  steps  to  execute  the  specified  command.  This 
subroutine  was  coded  using  the  design  given  for  the 
EXECUTE  COMMAND  module  in  the  figure  on  page  B-19. 
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Build  Message 

The  Build  Message  subroutine  builds  the  required 
message  that  is  transmitted  to  the  user.  These  messages 
fall  into  the  following  three  categories: 

1.  Prompts. 

2.  Command  formats. 

3.  System  messages. 

A  prompt  is  a  message  sent  to  the  user  that  is 
requesting  some  additional  information.  This  information 
can  consist  of  username,  password.  Data  Base  changes,  and 
others.  A  command  format  is  a  message  that  informs  the 
user  of  the  required  format  for  a  command.  This  message 
is  used  bj'  the  Help  User  subroutine.  A  system  message  is 
a  message  sent  to  inform  the  user  that  a  system  change  has 
been  completed. 

The  calling  subroutine  sends  a  single  coded  parameter 
used  in  the  seletion  of  the  message  that  is  to  be  sent  to 
the  user.  The  message  is  not  actually  'built,',  but  it  is 
defined  in  the  beginning  of  the  subroutine.  The  message 
is  then  sent  to  the  Transmit  Message  subroutine,  which 
needs  the  terminal's  port  number  that  the  message  is  to  be 
sent. 

This  subroutine  was  coded  using  the  design  given  for 
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the  BUILD  MESSAGE  module  in  the  figure  on  page  B-24.  The 
following  is  the  pseudocode  for  the  Build  Message 
subroutine : 

*  ★  ★  ★  * 

Procedure  Build  Message 
Define  Messages 
Case  message  code 
Code  =  0:  Send  no  help  message 
Code  =  1:  Send  run  command  format 
Code  =  2:  Send  list  command  format 
Code  =  3:  Send  print  command  format 
Code  =  4:  Send  delete  command  format 
Code  =  5:  Send  directory  command  format 
Code  =  6 :  Send  username  prompt 
Code  =  7:  Send  password  prompt 
Code  =  8:  Send  logged  out  message 
Code  =  9:  Send  login  complete  message 
Code  =10:  Send  job  done  message 
(  additional  messages  can  be  added  ) 

Default:  Send  no  message  error  (for  testing  purposes) 

End  case 

End  Procedure  Build  Message 

★  *  ★  *  * 
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Error  Handling 

Errors  are  handled  through  a  subroutine  called 
'Error',  and  then  control  is  returned  to  each  calling 
subroutine  indicating  an  error  was  received.  Having 
control  returning  to  each  calling  subroutine  indicating 
that  an  error  was  received,  allows  for  the  errors  to  be 
handled  efficiently.  The  Error  subroutine  performs  the 
same  type  of  function  as  the  Build  Message  subroutine 
does,  except  the  messages  that  are  sent  are  error 
messages.  This  means  that  the  error  messages  are  defined 
in  the  beginning  of  the  subroutine 

This  subroutine  was  coded  using  the  design  given  for 
the  BUILD  u.lROR  MESSAGE  module  in  the  figure  on  page  B-18. 
The  following  is  the  pseudocode  for  the  Error  subroutine: 

***** 


Procedure  Error 
Define  error  messages 
Case  error  message  code 


Code  =  1 : 

Send 

syntax  error  received 

Code  =  2: 

Send 

invalid 

filename 

Code  =  3  : 

Send 

improper 

user  retreiving  file 

Code  =  4 : 

Send 

illegal 

user  trying  to  log  in 
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Code 


5:  Send  unauthorized  user  attempting  to  do 


system  change 

Code  =  6:  Send  unreconizeable  was  received 
Code  =  7:  Send  not  enough  space  to  execute  job  at  this 
time 

Code  =  8:  Send  program  too  large  for  execution 
Code  =  9:  Send  process  was  aborted  before  completion 
Code  =  10:  Send  Non-Executable  file,  unable  to  run 
Code  =  11:  Send  Executable  file,  unable  to  print 
(additional  error  message  can  be  added  when  necessary) 
Default  :  Send  no  error  message  error  (for  testing 
purposes) 

End  case 

End  Procedure  Error 


*  *  *  *  * 


Static  Analysis 

Testing  the  source  code  requires  using  a  software 
testing  technique.  The  initial  testing  on  the  AMOS  source 
code  was  static  analysis.  Static  analysis  is  "a 
collection  of  analysis  and  testing  methods  that  do  not 
require  the  execution  of  the  subject  program"  (Ref.  24: 
5-1) .  The  capablities  that  static  analysis  can  accomplish 
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1.  Detect  and  locate  certain  types  of  program 
errors . 

2.  Identify  program  anomalies,  characteristics  that 
produce  errors. 

3.  Identify  constructions  that  do  not  conform  to  the 
standard  syntax. 

4.  Determine  whether  the  variables  are  used  in 
accordance  with  the  intentions  of  the  programmer. 

5.  Help  to  generate  test  data  for  dynamic  testing. 
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The  types  of  program  errors  that  are  looked  for  are 
infinite  loops,  module  interface  conflicts,  recursive 
procedure  calls,  and  uninitialized  variables  (Ref.  24: 
2-2) .  Because  the  design  was  evaluated  closely,  the  only 
program  errors  that  were  found  were  uninitialized 
variables.  This  was  the  result  of  a  programmer  forgetting 
to  initialize  counters  used  in  conditional  statements  and 
loops. 

One  program  anomaly  was  found,  using  static  analysis, 
and  corrected  in  the  design,  as  well  as  the  code.  This 
anomaly  was  the  deleting  of  two  seperate  files  on  the  same 
sector  that  are  on  two  seperate  processes  that  are  in 
ready  states.  The  original  design  and  code  would  delete 


the  first  file, 

but  when 

the 

next 

file 

is  deleted. 

the 

first  file  is 

restored 

and 

only 

the 

latter  file 

is 
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deleted.  This  was  resolved  by  making  the  DEL  command 
dedicated.  That  is,  the  command  is  executed  without 
interruptions.  This  ensures  that  a  second  DEL  command 
does  not  negate  the  first  DEL  command. 

The  syntax  was  tested  using  the  C  language  compiler. 
The  compiler  used  is  on  the  VAX  11/780  VMS  O/S.  This 
compiler  only  compiled  the  program  and  checked  the  syntax 
for  the  VAX  C  language,  not  for  the  standard  syntax  for 
the  C  language.  When  this  operating  system  is  transferred 
to  another  computer  system,  the  source  code  will  have  to 
be  recompiled  for  that  computer's  version  of  the  C 
language. 

A  variable  detected  that  was  not  used  as  it  was 
intended  was  'end.'  'End'  was  defined  in  the  global 
variables  as  a  right  bracket.  In  the  subroutine  Get-file, 
the'  variable  'end'  was  used  as  a  flag  that  indicated  an 
end  of  the  file  marker  was  found. 

The  test  data  that  can  be  used  for  the  dynamic 
testing  of  AMOS  could  be  the  scenario  inputs  that  were 
used  in  the  static  analysis.  These  scenario  inputs  are: 

1.  RUN  'any  parameter' 

2.  LIST  'any  parameter' 

3.  PRINT  'any  parameter' 

4.  DEL  'any  parameter' 

5.  DIR 
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6.  SYS  'any  parameter' 

7.  HELP  'any  parameter' 


8.  BYE 

9 .  ' any  parameter ' 

'Any  parameter*  is  input  that  is  valid  or  invalid. 
This  would  test  the  valid  cases  and  the  invalid  cases  of 
each  command.  A  carriage  return  would  be  considered  as  a 
parameter. 

Summary 

This  chapter  presented  the  alogrithms  and  pseudocode 
for  the  modules  implemented.  AMOS  is  mainly  constructed 
with  these  modules.  The  pseudocode  was  translated  into  a 
source  code  language ,  C.  The  source  code  was  developed  on 
the  VMS  Operating  System's  EDT  editor,  which  is  on  the  VAX 
11/780  located  in  the  Digital  Engineering  Lab. 


VII.  Conclusions  and  Recommendations 


Conclusions 


This  thesis  effort  was  concerned  with  the  detailed 
design  and  implementation  of  a  multiprogramming  operating 
system  for  sixteen-bit  microprocessors.  The  detailed 
design  consisted  of  reviewing  the  defined  system 
requirements  (Ref.  4  and  5)  and  following  the  top-level 
design  specifications,  in  the  form  of  data  flow  diagrams, 
to  construct  the  detailed  design.  The  implementation 
consisted  of  transferring  the  detailed  design  into  a 
structured  language,  that  is  C  language. 

The  detailed  design  looked  at  the  single  user 
environment  to  determine  the  processes  that  would  be 
necessary  for  the  operating  system.  This  was  the  majority 
of  the  operating  system  design  (Chapter  3)  .  The  design 
was  constructed  for  a  single  user  and  was  modified  to 
handle  a  multi-user  environment.  These  modifications 
consisted  of  inserting  a  scheduler  and  a  memory  manager. 

The  implementation  of  AMOS  followed  the  design, 
except  for  one  detail.  Global  variables  were  used  instead 
of  passing  parameters  between  modules,  because  passing 
structure  values  on  the  stack  is  impossible  in  C.  The 
only  variables  passed  between  modules  are  flags  and  a  few 


others,  such  as  track  locations,  sector  locations,  and 
command  types.  The  problem  of  passing  structure  values  on 
the  stack  was  also  encountered  in  a  previous  effort  (Ref. 
1:  66). 

This  thesis  effort  was  also  concerned  with  the  AMOS 
memory  manager  and  secondary  memory  specifications.  The 
detailed  design  of  the  memory  manager  was  constructed  by 
following  the  top-level  design  specifications,  in  the  form 
of  data  flow  diagrams  (Ref.  4:  81-83).  The  specifications 
for  the  secondary  memory  was  developed  in  conjunction  with 
memory  management  (Ref.  1:  44-61) . 

The  implementation  of  AMOS  memory  manager  was  done  by 
transferring  the  detailed  design  into  a  structured 
language.  Due  to  the  lack  of  device  drivers  secondary 
memory  management  was  not  implemented.  However,  the 
specifications  for  secondary  memory  was  developed  and 
presented  in  Chapter  5. 

The  objective  that  was  not  met  was  the  actual  running 
of  the  memory  manager  and  the  operating  system.  The 
operating  system,  including  the  memory  menager,  was 
logically  tested  using  static  analysis,  but  dynamic 
testing  was  not  accomplished.  Logically,  the  memory 
manager  will  provide  a  sufficient  means  of  handling  main 
memory  for  the  operating  system. 


Recommendations 


This  effort  does  not  complete  the  software 
development  cycle  for  AMOS.  The  testing  phase  and  the 
coding  of  assembly  language  subroutines  are  not  completed. 
Therefore,  the  source  code  has  to  be  transferred  from  the 
VMS  0/S  file  system  to  a  compatible  8  inch  floppy  disk  for 
the  Am  Z8000  system.  Also,  the  Z8000  system  must  be 
operational  with  a  disk  system,  before  the  transfer  can 
take  place  and  installation  of  AMOS  can  occur.  Follow-on 
thesis  efforts  are  recommended  to  complete  the  operating 
system's  software  development  cycle. 

Testing 

The  static  analysis  of  the  source  code  has  already 
been  completed  leaving  dynamic  testing  to  be  performed. 
This  dynamic  testing  should  include  module,  integration, 
system,  and  acceptance  testing  {Ref.  25:  232).  The 
completions  of  these  tests  should  be  extensive  to  insure  a 
working  product.  It  is  recommended  that  these  tests 
should  be  done  before  transfer  to  the  microcomputer 
system,  because  the  availability  of  software  tools,  for 
example,  a  compiler  and  an  editor. 

Module  testing  is  the  validation  of  a  single  module, 
usually  isolated  from  all  other  modules  (Ref.  25:  232). 


This  is  done  by  using  stubs  in  place  of  any  modules  that 
is  called  by  the  module  being  tested  and,  also,  by  using  a 
driver  to  execute  the  module. 

After  completion  of  module  testing,  integration 
testing  should  be  performed.  Integration  testing  is  a 
validation  of  the  interfaces  between  modules,  components, 
and  subsystems  (Ref.  25:  232).  This  testing  should  be 
done  in  a  top-down  fashion  in  order  to  prevent  errors  from 
propagating  down  to  lower-level  modules.  If  the  testing 
is  done  in  another  fashion,  an  error  that  is  found  in  a 
higher-level  module  interface  will  most  likely  propagate 
to  lower-level  modules  that  have  already  been  integrated. 

System  testing  is  the  validation  of  the  system  to  its 
initial  objectives:  it  is  a  validation  process  when  done 
in  a  simulated  environment  or  in  a  live  enviroment  (Ref. 
25:  232). 

Acceptance  testing  is  the  validation  of  the  system  to 
the  user  requirements  (Ref.  25:  232) ,  which  are  defined  in 
Chapter  2. 

Assembly  Coded  Routines 

The  assembly  coded  routines  necessary  for  an 
operational  system  are  the  device  drivers  and  a  kernel  for 
the  scheduler.  The  device  drivers  might  be  obtained  from 
existing  software,  such  as  an  existing  operating  system 


.»>Y» 
1  >£> 


>?? 


rr>  1 


for  the  microcomputer.  The  kernel  will  have  to  be 
written,  because  it  will  have  to  meet  the  specifications 
and  design  of  the  scheduler. 


Source  Code  Transfer 


Currently  the  source  code  is  located  on  the  VMS  O/S's 
disk  storage  and  will  have  to  be  transferred  to  an  8  inch 
floppy  disk.  This  can  be  done  by  performing  the  following 
steps: 


Transfer  the  source  code  onto  a  magnetic  tape 
from  the  VMS  disk  storage. 

Transfer  the  source  code  from  the  magnetic  tape 
to  UNIX  disk  storage. 

Make  any  necessary  syntax  changes  that  makes  the 
code  compatible  with  the  UNIX  O/S. 

Cross-compile  the  source  code  from  C  to  Z8000 
assembly  code  by  using  the  cross-complier 
available  for  the  UNIX  0/S  (Ref.  1:  67). 

Transfer  the  Z8000  assembly  code  to  an  8  inch 
floppy  disk  that  has  a  compatible  format  for 
the  Z8000  system. 
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Operational  Z8000  System 


One  way  for  the  system  to  be  operational,  the 
hardware  components  must  be  compatible  and  connected,  and 
a  developmental  operating  system  with  a  Z8000  assembler 
must  be  obtained.  The  developmental  operating  system  is 
needed  to  execute  the  Z8000  assembler,  so  that  the  AMOS 
assembly  code  can  be  converted  to  executable  code. 
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Initial  Hardware  Configuration 


The  initial  hardware  configuration  for  the  AFIT 
Multiprogramming  Operating  System  (AMOS)  is  based  on  two 
factors : 


1.  The  requirements  that  were  defined  for  the 

microprocessor's  computer  sytem. 

2.  The  availability  of  the  microprocessor  and  the 

compatible  hardware  necessary  to  construct  the 

computer  system. 

The  microprocessor  was  selected  earlier  (Ref.  1)  and 
is  the  AMD  Z8002.  The  selection  of  the  Z8002  was 

discussed  on  page  11-14.  The  Digital  Engineering  Lab  has 
an  available  AMD  Z8002  microprocessor  based  computer 
system  which  consists  of  the  following: 


1. 

Heathkit  terminal  (1) 

2. 

Heathkit  H27 

Floppy  Disk  Drives 

(Double) 

3. 

Am 

96/4116A 

Monoboard  with  Z8002 

microprocessor 

4. 

Am 

95/6120 

Intelligent  Floppy  Disk  Controller 

5. 

Am 

96/1128 

128K  Dynamic  RAM  Board 

6. 

Am 

95/5132 

RAM-EPROM-I/O  Board 

7.  Amc  95/6011  Arithmetic  Processing  Unit  Board 

8.  Am  95/6452  Card  Cage 

For  the  implementation  of  a  multiuser  environment,  it 
is  recommended  that  the  standard  multibus  serial  interface 
card  should  be  incorporated  with  the  above  hardware.  More 
terminals  would  also  be  required.  Other  units  or 
peripherals  can  be  added  to  the  system  when  the  need,  or 
opportunity,  arises. 

The  Am  96/4116  Monoboard  contains  two  RS232  serial 
I/O  ports,  24  parallel  I/O  lines,  five  programmable 
counter/ timer  at  4  MHz,  and  power-fail  capability  (Ref. 
21:1).  Further  specifications  can  be  found  in  Reference 
21.  The  specifications  for  the  other  AMD  products  are  in 
the  following  manuals: 

1.  Am  95/6120  Dual  Density  Floppy  Disk  Controller 
User's  Manual 

2.  Am  96/1000  Series  Dynamic  Random-Access  Memory 
Boards  User's  Manual 

3.  Am  95/5132  PROM/ROM/RAM  and  I/O  Board  User's 
Manual 

4.  Amc  95/6011  Arithmetic  Processing  Unit  Board 
User's  Manual 

5.  Am  95/6452  Card  Cage  User's  Manual 
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Appendix  B 

AMOS  Structure  Charts 

This  appendix  contains  the  structure  charts  for  AMOS. 
The  structure  charts  contain  the  modules  designed  in 
Chapter  3  and  both  the  modules  designed  for  the  Memory 
Management  and  Process  Management.  The  process 
descriptions  and  data  flow  entries  are  located  in 
Appendices  C  and  D,  respectively. 
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Load  AMOS  into  Memory 
Execute  AMOS 

Execute  AMOS .  B-7 

Initialize  Data  Base 
Parse  Command  Line 
Determine  Valid  Command 


Initialize  Data  Base .  B-8 
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Check  Filename 
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Check  Filename 
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Validate  Print  Command.... 

Check  Filename 
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Validate  Delete  Command. 

Check  Filename 
Check  Username 

Check  Filename . 

Open  File 

Get  Username 

Build  Error  Message 

Check  Username . 

Build  Error  Message 

Build  Error  Message . 

Transmit  Message 

Execute  Command . 

Get  File 

Process  Scheduler 

Get  File . 

Check  Space 
Build  PCB 
Read  File 

Build  Error  Message 

Build  PCB . 

Insert  PCB  into  Queue 

Check  Space . 

Sort  Memory  Location 
Build  Error  Message 

Logout  User . 

Clear  User  Parameters 
Build  Message 

Build  Message . 


Transmit  Message 


Help  User 


Get  System  Information 
Get  Command  Information 
Build  Message 


System  Change  (Modified) 

Verify  Authority 
Build  PCB 
Process  Scheduler 


System  Change 


Verify  Authority 
Configure  System 


Verify  Authority. 


Check  User's  Authority 
Build  Error  Message 


Configure  System. 


Build  Message 
Read  Command  Line 


Process  Scheduler. 


Process  I/O  Wait  Queue 
Get  PCB 
Run  Process 
Build  Error  Message 


Process  I/O  Wait  Queue, 


Locate  Unblocked  Process 
Delete  PCB  For  I/O  Wait  Queue 
Insert  PCB  into  Queue 


Get  PCB. 


Check  Ready  Queues 
Get  PCB  from  Queue 


Run  Process, 


Run  System  Change 

Send  File  To  Port 

Write  File  to  Secondary  Memory 

Deallocate  Memory  Space 

Run  Program 


Clean  Up  Queue 


Delete  PCB  from  I/O  Wait  Queue 
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Process  Description  for  AMOS 

This  appendix  contains  the  process  description  of 
each  structure  module.  The  structure  charts  are  located 
in  Appendix  B. 


PROCESS  NAME:  Execute  Bootstrap  Program 
PROCESS  NUMBER:  1.0 

PROCESS  DESCRIPTION:  This  process  loads  the  operating 
system  from  secondary  memory  into  main  memory.  Upon 
completion  of  this  the  operating  system  is  then  executed. 

PROCESS  NAME:  Load  AMOS  Into  Memory 
PROCESS  NUMBER:  1.1 

PROCESS  DESCRIPTION:  This  process  retrieves  the  operating 
system  from  secondary  memory  and  places  into  main  memory. 

PROCESS  NAME:  Execute  AMOS 
PROCESS  NUMBER:  1.2 

PROCESS  DESCRIPTION:  This  process  executes  the  operating 
system  that  has  already  been  loaded  into  main  memory. 

PROCESS  NAME:  Initialize  Data  Base 
PROCESS  NUMBER:  1.2.1 

PROCESS  DESCRIPTION:  This  process  sets  the  initial  values 
for  specific  data  items  used  by  the  operating  system. 

PROCESS  NAME:  Parse  Command  Line 
PROCESS  NUMBER:  1.2.2 

PROCESS  DESCRIPTION:  This  process  polls  the  on-line 
terminals,  reads  the  next  command  line,  and  parses  the 
command  line  into  a  command  table.  Process  scheduler  is 
called  when  terminals  are  idle. 

PROCESS  NAME:  Determine  Valid  Command 
PROCESS  NUMBER:  1.2.3 

PROCESS  DESCRIPTION:  This  process  determines  the  requested 
command  and  then  checks  for  validity.  If  the  command  is 
found  to  be  valid,  it  is  then  executed. 

PROCESS  NAME:  Retrieve  Data  Base  Information 
PROCESS  NUMBER:  1.2. 1.1 

PROCESS  DESCRIPTION:  This  process  retrieves  the 

information  that  is  used  to  initialize  the  operating 
system's  variables. 


PROCESS  NAME:  Initialize  Variables 
PROCESS  NUMBER:  1.2. 1.2 
PROCESS  DESCRIPTION:  This  process 

operating  system's  variables  with 
information. 


initializes  the 
the  Data  Base 


PROCESS  NAME:  Poll  Terminal  Ports 
PROCESS  NUMBER:  1.2. 2.1 

PROCESS  DESCRIPTION:  This  process  uses  a  algorithm  to  poll 
the  terminal  ports  to  check  for  user  requests. 

PROCESS  NAME :  Read  Command  Line 
PROCESS  NUMBER:  1.2. 2. 2 

PROCESS  DESCRIPTION:  This  process  reads  the  command  line 
from  the  given  port. 

PROCESS  NAME:  Build  Command  Table 
PROCESS  NUMBER:  1.2. 2. 3 

PROCESS  DESCRIPTION:  This  process  oreaks  the  command  line 
into  separate  parameters.  These  parameters  are  then 
placed  into  the  command  table. 

PROCESS  NAME:  Log-in  User 
PROCESS  NUMBER:  1.2. 3.1 

PROCESS  DESCRIPTION:  This  process  checks  to  see  if  the 
user  is  already  logged-in.  If  found  to  be  logged-in,  then 
control  is  returned  to  calling  module.  Otherwise  the  user 
is  attempted  to  be  logged-in.  The  user  is  prompted  for 
the  username  and  password  and  reads  the  user's  input.  The 
username  and  password  are  verified.  If  they  are  valid, 
then  the  user  block  is  initialized. 

PROCESS  NAME:  Log-out  User 
PROCESS  NUMBER:  1.2. 3. 2 

PROCESS  DESCRIPTION:  This  process  clears  the  user  block 
for  the  terminal  which  the  log-out  command  originated. 

PROCESS  NAME:  Help  User 
PROCESS  NUMBER:  1.2. 3. 3 

PROCESS  DESCRIPTION:  This  process  provides  the  user  with 
the  requested  system  or  command  information,  if  available. 

PROCESS  NAME:  System  Change 
PROCESS  NUMBER:  1.2. 3. 4 

PROCESS  DESCRIPTION:  This  process  verifies  that  the  user 
is  the  'Superuser.'  If  found  to  be  the  'Superuser,'  then 
the  system  is  reconfigured  with  the  changes  specified  by 
the  'Superuser.' 
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PROCESS  NAME:  Execute  User  Command 
PROCESS  NUMBER:  1.2. 3. 5 

PROCESS  DESCRIPTION:  This  process  determines  if  the 
specified  user  command  is  valid.  If  the  command  is  valid, 
the  command  is  then  placed  into  main  memory  for  execution. 

PROCESS  NAME:  Set-up  User  Parameters 
PROCESS  NUMBER:  1.2. 3. 1.1 

PROCESS  DESCRIPTION:  This  process  initializes  the  user 
block  parameters. 

PROCESS  NAME:  Build  Message 
PROCESS  NUMBER:  1.2. 3. 1.2 

PROCESS  DESCRIPTION:  This  process  constructs  a  message  to 
be  sent  to  a  user  and  calls  the  Transmit  Message  module. 

PROCESS  NAME:  Clear  User  Parameters 
PROCESS  NUMBER:  1.2. 3. 2.1 

PROCESS  DESCRIPTION:  This  process  clears  the  user  block 
parameters  for  the  terminal  which  the  log-out  command 
originated . 

PROCESS  NAME:  Get  System  Information 
PROCESS  NUMBER:  1.2. 3. 3.1 

PROCESS  DESCRIPTION:  This  process  retrieves  the  requested 
system  information  and  sends  the  information  to  the  user. 

PROCESS  NAME:  Get  Command  Information 
PROCESS  NUMBER:  1.2. 3. 3. 2 

PROCESS  DESCRIPTION:  This  process  retrieves  the  requested 
command  information  and  sends  the  information  to  the  user. 

PROCESS  NAME:  Verify  Authority 
PROCESS  NUMBER:  1.2. 3. 4.1 

PROCESS  DESCRIPTION:  This  process  verifies  that  the  user 
is  the  'Superuser.' 

PROCESS  NAME:  Configure  System 
PROCESS  NUMBER:  1.2. 3. 4. 2 

PROCESS  DESCRIPTION:  This  process  configures  the  system's 
Data  Base  with  the  new  information  that  is  given  by  the 
'  Superuser . ' 

PROCESS  NAME:  Validate  User  Command 
PROCESS  NUMBER:  1.2. 3. 5.1 

PROCESS  DESCRIPTION:  This  process  checks  for  validity  of 
the  specified  user  command  (i.e.  RUN,  LIST,  PRINT,  DEL, 
and  DIR) . 


PROCESS  NAME:  Execute  Command 
PROCESS  NUMBER:  1.2. 3. 5. 2 

PROCESS  DESCRIPTION:  This  process  retrieves  a  file  and 
calls  the  Process  Scheduler  module  for  execution. 

PROCESS  NAME:  Check  User 
PROCESS  NUMBER:  1.2. 3. 1.1.1 

PROCESS  DESCRIPTION:  This  process  checks  the  user  table  to 
determine  if  the  user  is  allowed  system  access. 

PROCESS  NAME:  Transmit  Message 
PROCESS  NUMBER:  1.2. 3. 1.2.1 

PROCESS  DESCRIPTION:  This  process  sends  a  message  to  the 
user. 

PROCESS  NAME:  Check  User  Authority 
PROCESS  NUMBER:  1.2. 3. 4. 1.1 

PROCESS  DESCRIPTION:  This  process  checks  to  see  if  the 
user  is  the  'Superuser.' 

PROCESS  NAME:  Validate  Run  Command 
PROCESS  NUMBER:  1.2. 3. 5. 1.1 

PROCESS  DESCRIPTION:  This  process  checks  the  username  and 
the  file  for  validity. 

PROCESS  NAME:  Validate  List  Command 
PROCESS  NUMBER:  1.2. 3. 5. 1.2 

PROCESS  DESCRIPTION:  This  process  checks  the  username  and 
the  file  for  validity. 

PROCESS  NAME:  Validate  Print  Command 
PROCESS  NUMBER:  1.2. 3. 5. 1.3 

PROCESS  DESCRIPTION:  This  process  checks  the  username  and 
the  file  for  validity. 

PROCESS  NAME:  Validate  Delete  Command 
PROCESS  NUMBER:  1.2. 3. 5. 1.4 

PROCESS  DESCRIPTION:  This  process  checks  the  username  and 
the  file  for  validity. 

PROCESS  NAME :Get  File 
PROCESS  NUMBER:  1.2. 3. 5. 2.1 

PROCESS  DESCRIPTION:  This  process  checks  the  space, 
retrieves  a  file  from  secondary  memory,  places  into  main 
memory,  and  builds  a  Process  Control  Block. 


PROCESS  NAME:  Process  Scheduler 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2 

PROCESS  DESCRIPTION:  This  process  retrieves  the  unblocked 
Process  Control  Blocks  in  the  I/O  Wait  Queue  and  places 
them  into  the  Ready  Queue,  gets  the  next  process  to  be 
executed,  and  executes  the  process.  If  there  is  no 
process  that  is  ready  to  run,  then  control  is  returned  to 
the  calling  module. 

PROCESS  NAME:  Check  Filename 
PROCESS  NUMBER:  1.2. 3. 5. 1.1.1 

PROCESS  DESCRIPTION:  This  process  determines  if  a  file  is 
located  in  secondary  memory. 

PROCESS  NAME:  Check  Username 
PROCESS  NUMBER:  1.2. 3. 5. 1.1. 2 

PROCESS  DESCRIPTION:  This  process  determines  if  the  user 
has  authority  to  access  the  file. 

PROCESS  NAME:  Check  Run  Filename 
PROCESS  NUMBER:  1.2. 3. 5. 1.1. 3 

PROCESS  DESCRIPTION:  This  process  determines  if  a  file  is 
an  executable  file. 

PROCESS  NAME:  Check  Space 
PROCESS  NUMBER:  1.2. 3. 5. 2. 1.1 

PROCESS  DESCRIPTION:  This  process  determines  if  there 
exists  enough  space  for  an  incoming  file. 

PROCESS  NAME:  Build  PCB 
PROCESS  NUMBER:  1.2. 3. 5. 2. 1.2 

PROCESS  DESCRIPTION:  This  process  builds  a  Process  Control 
Block  for  the  command. 

PROCESS  NAME:  Read  File 
PROCESS  NUMBER:  1.2. 3. 5. 2. 1.3 

PROCESS  DESCRIPTION:  This  process  reads  a  file  from 
secondary  memory  and  places  it  into  main  memory. 

PROCESS  NAME:  Process  I/O  Wait  Queue 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2.1 

PROCESS  DESCRIPTION:  This  process  takes  those  processes 
that  are  finished  with  their  I/O  wait  out  of  the  I/O  Wait 
Queue  and  places  them  into  the  appropriate  Ready  Queue. 

PROCESS  NAME:  Get  PCB 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2. 2 

PROCESS  DESCRIPTION:  This  process  retrieves  the  PCB  of  the 
next  ready  process  to  executed. 


PROCESS  NAME:  Run  Process 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2. 3 

PROCESS  DESCRIPTION:  This  process  executes  the  process  of 
the  given  PCB. 

PROCESS  NAME:  Open  File 
PROCESS  NUMBER:  1.2. 3. 5. 1.1. 1.1 

PROCESS  DESCRIPTION:  This  process  opens  a  file  located  in 
secondary  memory  for  reading  and  writing. 

PROCESS  NAME:  Get  Username 
PROCESS  NUMBER:  1.2. 3. 5. 1.1. 1.2 

PROCESS  DESCRIPTION:  This  process  gets  the  username  of  the 
requested  file. 

PROCESS  NAME:  Build  Error  Message 
PROCESS  NUMBER:  1.2. 3. 5. 1.1. 1.3 

PROCESS  DESCRIPTION:  This  process  constructs  an  error 
message  that  is  the  transmitted  to  the  user. 

PROCESS  NAME:  Sort  Memory  Locations 
PROCESS  NUMBER:  1.2. 3. 5. 2. 1.1.1 

PROCESS  DESCRIPTION:  This  process  arranges  the  memory 
locations  of  all  jobs  in  main  memory  from  smallest  to 
largest. 

PROCESS  NAME:  Insert  PCB 
PROCESS  NUMBER:  1.2. 3. 5. 2. 1.2.1 

PROCESS  DESCRIPTION:  This  process  inserts  the  given  PCB 
into  the  appropriate  queue. 

PROCESS  NAME:  Locate  Unblocked  Processes 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2. 1.1 

PROCESS  DESCRIPTION:  This  process  locates  all  PCBs  in  the 
I/O  Wait  Queue  that  are  no  longer  in  an  I/O  wait  state. 

PROCESS  NAME:  Delete  PCB  From  I/O  Wait  Queue 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2. 1.2 

PROCESS  DESCRIPTION:  This  process  deletes  the  given  PCBs 
from  the  I/O  Wait  Queue. 

PROCESS  NAME:  Check  Ready  Queue 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2. 2.1 

PROCESS  DESCRIPTION:  This  process  checks  the  Ready  Queues 
for  a  ready  PCB  and  returns  the  Ready  Queue's  number. 

PROCESS  NAME:  Get  PCB  From  Queue 
PROCESS  NUMBER:  1.2. 3. 5. 2. 2. 2. 2 

PROCESS  DESCRIPTION:  This  process  retrieves  the  PCB  from 
the  given  Ready  Queue. 


Data  Dictionary  for  AMOS 


This  appendix  contains  the  data  flow  entrys  that  are 
passed  between  the  structure  chart  modules.  The  structure 
charts  are  located  in  Appendix  B.C 


1.  DATA  NAME:  AMOS 

This  is  the  object  code  of  the  operating  system. 
It  is  transferred  to  main  memory  (at  a  set  location) 
from  secondary  memory. 

2.  DATA  NAME:  AMOS-Global-Variables 

These  are  the  data  items  that  are  used  by  the 

operating  system  and  contains  all  of  the  data  flow 
items . 

3.  DATA  NAME:  Authorized/Unauthorized-User 

ALIASES:  Error-Flag 

This  is  a  flag  that  informs  the  operating  system 
that  the  user,  who  is  requesting  a  system  command 
operation,  is  or  is  not  the  'Superuser. 1 

4.  DATA  NAME:  Command-Help 

This  is  a  request  for  command  information. 

5.  DATA  NAME:  Command-Information 

This  is  the  command  information  that  was 
requested  by  the  user 

6.  DATA  NAME:  Command-Line 

ALIASES:  New-System-Inf ormation 

The  data  sent  to  the  operating  system  by  the 
user  that  is  terminated  by  a  carriage  return.  It 
will  contain  a  command  and  any  necessary  parameters. 

7.  DATA  NAME:  Command-Table 

All  of  the  parameters  from  the  Command  Line  (6) 
and  any  other  parameters  that  are  acquired  by  any 
promt ing  routine. 


DATA  NAME:  Da ta-Base-Inf ormation 

These  are  the  initial  values  that  the 
AMOS-Global-Variables  (2)  are  set. 

DATA  NAME:  Error-Flag 

This  is  a  frag  that  is  sent  to  the  Error  routine 
to  build  an  Error-Message  (10) . 

DATA  NAME:  Error-Message 

This  is  a  message  informing  the  user  that  an 
error  has  occurred  and  what  it  was. 

DATA  NAME:  Filename 

This  is  the  name  of  a  file  that  has  an  operation 
that  is  to  be  performed  on  it.  (such  as  Run  or  List) 

DATA  NAME:  File-Descriptor 

This  is  an  integer  indicating  where  the  file  is 
located  in  a  buffer  of  all  open  files. 

DATA  NAME:  File ' s-Username 

This  is  the  username  of  the  file  that  is  being 
requested  by  a  user. 

DATA  NAME:  I /O-Wait-Queue 

This  is  the  pointer  to  the  I/O  Wait  Queue. 

DATA  NAME:  Legal/ll legal-User 
ALIASES:  Error-Flag 

This  is  a  flag  indicating  that  the  user  has 
access,  or  doesn't  have  access,  to  AMOS. 


DATA  NAME:  Logged-In 
ALIASES:  Message-Code 

This  is  a  flag  indicating  that  the  user  has  been 
properly  logged-in. 

DATA  NAME :  Logged-Out 
ALIASES:  Message-Code 

This  is  a  flag  indicating  that  the  user  has  been 
properly  logged-out. 


18.  DATA  NAME:  Memory-Location 

The  location  in  main  memory  that  a  file  is 
located  or  is  being  sent. 

19.  DATA  NAME:  Message-Code 

This  is  a  flag  that  is  used  by  the  Build  Message 
routine  to  build  a  message  that  is  sent  to  the  user. 

20.  DATA  NAME:  No-Space-Available 

ALIASES:  Error-Flag 

This  is  a  flag  indicating  that  there  isn't 
enough  available  memory  space  for  the  execution  of 
the  process. 

21.  DATA  NAME:  Ordered-Memory-Locations 

This  is  the  table  of  the  available  memory 
partitions  ordered  by  size  and  is  used  by  the  Memory 
Manager. 

22.  DATA  NAME:  Password 

This  is  the  user's  unique  key  to  the  operating 
system.  It  can  be  changed  by  the  user  and  is  entered 
by  the  user. 

23.  DATA  NAME:  PCB  (Process  Control  Block) 

This  is  a  table  that  is  used  by  the  Process 
Manager  to  keep  track  of  all  the  processes  that  are 
submitted  to  run. 

24.  DATA  NAME:  Portno 

The  port  number  that  a  message  is  being  sent  or 
a  command  is  being  received. 

25.  DATA  NAME:  Process-Aborted 

ALIASES:  Error-Flag 

This  is  a  flag  that  is  sent  to  the  user 
indicating  that  the  submitted  process  was  aborted. 

26.  DATA  NAME:  Process-Memory-Locations 

This  is  the  table  of  unordered  available  memory 
partitions . 


DATA  NAME:  Program-Too-Large-For-Memory 
ALIASES :  Not-Too-Large/Too-Large , 

Error-Flag 

This  is  a  flag  to  indicate  to  the  Memory  Manager 
that  the  incoming  file  is  not  small  enough  for  all  of 
main  memory. 

DATA  NAME :  Prompt 

ALIASES:  Message,  System-Change 

This  is  a  message  to  the  user  to  indicate  that 
information  is  to  be  entered.  This  information  can 
include  the  Username  (34)  or  Password  (22). 

DATA  NAME:  Queues-Empty/Not-Empty 

This  is  a  flag  indicating  that  the  Ready  Queues 
are  empty,  or  not  empty. 

DATA  NAME :  Queue -Number 

This  is  a  number  that  indicates  to  the  Process 
Manager  which  Ready  Queue  has  the  next  process  to 
run. 

DATA  name :  Syntax-Error 
ALIASES:  Error-Flag 

This  is  a  control  flag  to  indicate  that  a 
command  is  not  found.  This  control  flag  is 
transmitted  to  an  error  handling  routine. 

DATA  NAME:  System-Help 

This  is  a  request  for  system  information. 

DATA  NAME:  System-Information 

This  is  the  system  information  that  was 
requested  by  the  user. 

DATA  NAME:  Username 
ALIASES:  Portno 1 s-Username , 

Superuser ' s-Username 


This  is  the  user's  indentif ication  used  to  log 
onto  the  operating  system.  It  cannot  be  changed  by 
the  user  and  is  entered  by  the  system's  'Superuser.' 


DATA  NAME:  Valid/Invalid-Filename 
ALIASES:  Error-Flag 

This  is  a  flag  that  indicates  that  the  file  the 
user  has  requested  an  operation  on  exists,  or  doesn't 
exist. 

DATA  NAME:  Valid/ Invalid-Username 
ALIASES:  Error-Flag 

This  is  a  flag  that  indicated  that  the  file  the 
user  is  requesting  is,  or  isn't,  their  file. 


Appendix  E 

AMOS  Source  Code 

This  appendix  contains  the  source  code  for  AMOS.  It 
is  in  the  file  AMOS.C  on  the  VMS  O/S's  disk  storage.  The 
documentation  in  the  code  consists  of  a  header  for  each 


subroutine  and  comments  throughout  the  C  language  code. 
The  header  is  based  on  Dr.  Gary  Lamont's  standards  that 
were  given  in  EE  6.86,  Information  Structures. 


y****************************************************************/ 

/*  Title:  AMOS:  AFIT  Multiprogramming  Operating  System  */ 

/*  V 

/*  Date:  31  August  1983  */ 

/*  Version:  1.0  */ 

/*  V 

/*  Filename:  AMOS.C  */ 

/*  Function:  This  is  a  multiprogramming  operating  system  */ 

/*  for  sixteen-bit  microprocessor  systems.  */ 

/*  Calling  Subroutines:  When  implemented  on  a  micro-  */ 

/*  processing  system,  a  boot  program  will  load  */ 

/*  this  0/S  and  will  proceed  to  execute  the  O/S  */ 

/*  Authors:  Paul  E.  Cruser  and  Ronald  K.  Miller  */ 

/*  V 

/*************************************************************'***y' 

/**/ 

/**/ 

/A***************************************************************/ 

/*  The  following  is  the  Global  Data  Base  that  will  be  */ 

/*  used  throughout  the  operating  system.  */ 

y'****************************************************************/ 

/**/ 


♦include  stdio.h 
♦define  superuser 


standard  input-output  library 


♦define  sprpass  "MOCNBEAK 


♦define 

♦define 

♦define 

♦define 

♦define 


userl 
user2 
pas  si 
pass2 
noports 


"CRDSERP 

"MILLERRK 


♦define  deviceports 

♦define  begin 
♦define  end 
♦define  BBGINUSER 

♦define  ENDUSER 

♦define  DIRTPACK 
♦define  DIRSECTOR 
♦define  ERROR 
♦define  NOMSEC 
♦define  ECFLaJGTH 


"SUPERMAN"  /*  this  is  the  superusers*/ 
/*  username  */ 

"MOCNBEAK"  /*  this  is  the  superusers  */ 
/*  password  */ 

"CRDSERP  *  /*  username  for  first  user*/ 
"MILLERRK"  /*usemame  for  second  user*/ 
"GCS-83D  *  /*  password  for  first  user*/ 
"LINDAWM  "  /*pas sword  for  second  user*/ 
4  /*  this  is  the  number  of  online  */ 

/*  terminal  ports  */ 

0  /*  this  is  the  number  of  online  */ 

/*  device  ports  */ 

{  /*  personal  preference  for  */ 

}  /*  easier  coding  */ 

13  /*  used  in  the  directory  to  mark*/ 
/*  the  column  */ 

20  /*  of  the  beginning  and  ending  */ 


/* 

of  the  username 

V 

0 

/* 

Directory  track  number 

V 

0 

/* 

Directory  sector  number 

V 

-1 

/* 

file  can't  be  opened  flag 

V 

16 

/* 

number  of  sectors  on  a  disk 

V 

40 

/* 

number  of  buffer  rows  for  the*/ 

/* 

directory 

V 

24 

/* 

number  of  buffer  column  f.t.d*/ 

40 

/* 

size  of  the  message 

V 

23 

/* 

byte  location  of  file  size 

V 

found  in  the  directory  buffer*/ 


♦define  BUFSIZE 
♦define  MESSIZE 
♦define  BEGSIZE 


♦define 

BEGTCACK 

21 

/* 

byte  location  of  the  first 

*/ 

/* 

track  in  the  directory  buffer*/ 

fdefine 

BEGSECTQR 

22 

/* 

byte  location  of  first  sector*/ 

/* 

in  the  directory  buffer 

V 

♦define 

OFFSET 

40 

/* 

ASCII  offset 

V 

♦define 

MAXJOBS 

4 

/* 

Maximun  no.  of  jobs  allowed 

V 

/* 

on  the  systen 

V 

♦define 

NAMESIZE 

12 

/* 

The  size  of  a  filename 

*/ 

♦define 

DISKSTAT 

0 

/* 

The  disk  status  bit 

*/ 

♦define 

DISKRDA 

0 

/* 

The  disk  ready  bit 

V 

♦define 

DISKPOFT 

0 

/* 

The  disk  dataport 

V 

♦define 

OOMMSIZE 

5 

/* 

The  max  size  of  a  command 

V 

♦define 

PARASIZE 

12 

/* 

The  max  size  of  a  parameter 

*/ 

♦define 

BASEJCCRESS  200  /* 

Start  address  of  user  memory 

V 

♦define 

TOP _jADERESS  OxFFFF  /*  End  address  of  main  memory 

*/ 

♦define 

ETCTELSIZE 

128 

/* 

Number  of  bytes  in  a  block 

V 

/*  from  the  disk  */ 


/*  the  following  structure  defines  the  process  control  */ 
/*  blocks  temppcb  and  pcb[]  are  pcb  that  will  be  used  by  */ 
/*  the  scheduler  */ 

struct  z8pcb  { 

struct  z8pcb  *next_cb, 

/*  next  pcb  in  the  queue  */ 
*previous_cb; 

/*  previous  pcb  in  the  queue  */ 
int  priority, 

/*  used  to  determine  queue  to  put  into  */ 

/*  Os  system  queue  */ 

/*  1:  readyl  queue  */ 

/*  etc.  */ 

currentjq, 

/*  indicates  what  queue  it  resides  in  */ 
/*  0:  system  queue  */ 

/*  1:  readyl  queue  */ 

/*  etc.  */ 

/*  -Is  i/o  wait  queue  */ 

processjdata, 

/*  to  be  used  in  later  implementation  */ 
/*  for  the  address  of  data  workspace  */ 

/*  for  the  process  */ 

offset_address, 

/*  where  the  beginning  address  of  */ 
/*  allocated  memory  is  located  */ 


final  address. 


/*  where  the  final  address  of  the  */ 
/*  allocated  memory  is  located  */ 

ccmmancLtype, 

/*  this  is  set  to  tell  the  system  what  */ 
/*  kind  of  command  is  being  executed  */ 
/*  -Is  SYS  command  */ 

/*  0:  RUN  command  */ 

/*  1*  LIST  command  */ 

/*  2:  PRINT  command  */ 

/*  3:  ML  command  */ 

/*  4s  DIR  command  */ 

/*  5:  EDIT  command  */ 

/*  note:  EDIT  isn't  available  V 
/*  and  others  may  be  added  as  */ 
/*  they  are  needed  */ 

por  t_of _or  i  gin , 

/*  port  number  that  the  pcb's  process  */ 
/*  originated  from  */ 


io_status; 

/*  indicates  if  process  is  in  an  io  wait  */ 
/*  or  not,  and  determines  if  the  process  */ 


/*  should  be  taken  out  of  the  io  wait  q  */ 
/*  Os  not  waiting  for  io  */ 

/*  Is  waiting  for  io  */ 

pcb [noports] ; 

/*  the  following  is  the  headers  for  the  I/O  Wait  queue  */ 

/*  and  the  Ready  queue.  Uiis  is  where  other  queues  */ 

/*  would  be  defined  when  they  are  added  later.  */ 


struct  qheader  { 

struct  z8pcb  *start, 

/*  pointer  to  first  pcb  in  list  */ 
♦ending; 

/*  pointer  to  last  pcb  in  list  */ 
int  qcount; 

iowaitq,  /*  header  for  I/O  Wait  queue  */ 

systemq,  /*  header  for  system  ready  queue  */ 

readylq;  /*  header  for  ready 1  queue  */ 


/*  the  following  structure  defines  the  ports'  data  table  */ 
struct  portdata  { 

int  statport, 

/*  this  is  the  status  port  address  */ 


dataport, 

/*  this  is  the  data  port  address  */ 
sendbit, 

/*  this  is  the  send  bit  mask  */ 
recvbit; 

/*  this  is  the  receive  bit  mask  */ 

} 

ports [noports +1] ;  /*  ports'  data  table  */ 

/*  the  noports+1  ports  will  be  for  */ 
/*  the  printer  port  information  */ 

/*  the  following  structure  defines  the  device  table  */ 

struct  dev_table  { 

char  device_type  [10]  ; 

/*  used  in  the  SYS  DEV  */ 
/*  to  indicate  what  the  */ 
/*  device  is  */ 

int  controlport, 

/*  the  address  of  the  control  port  */ 
port_data; 

/*  the  address  of  the  data  port  */ 

} 

device_table [deviceports] ; 

/*  the  following  structure  defines  the  terminal-user  table  */ 
struct  userblock  { 

int  loggedon,  /*  the  logged  on  flag:  */ 
jobrunning;  /*  is  a  job  running:  */ 
/*  0-no ,1 -yes  */ 

^char  usemm[8] ;  /*  the  logged  on  user  */ 

user blocks [noports] ; 

/*  the  userblocks'  subscript  (noports)  will  be  used  to  */ 
/*  indicate  which  terminal  is  being  used  by  the  usemm[]  */ 

/*  the  following  structure  defines  the  user table  */ 

/*  usertable[]  is  the  table  */ 

struct  usrtable  { 

char  username  [  8] , 
password  [  8] ; 

} 

usertable[40] ; 

/*  the  following  structure  defines  the  delete  table  */ 

/*  this  table  is  used  to  delete  files  that  users  */ 

/*  want  deleted  that  are  on  the  same  sector/track  */ 


/*  this  will  save  tine  writing  to  the  disk  and  will  */ 
/*  also  prevent  overwrite  */ 


struct  del_table  { 

int  track,  sector,  /*  track  and  sector  */ 
portno [MAXJCBS] ,  /*  port  numbers  of*/ 
/*  jobs  using  delete  for  */ 
/*  this  sector  and  track  */ 
del^oount, 

/*  number  of  deletes  to  perform  */ 
/*  for  this  track  and  sector  */ 
row  [MAXJCBS]; 

/*  array  of  the  rows  to  be  */ 
/*  deleted  on  the  given  track  */ 
/*  and  sector  */ 

} 

delete_table  [MAXJOBS]  ; 


/*  the  following  are  various  integer  and  character  */ 

/*  declarations  used  throughout  the  system  */ 

int  pol^Jportno, 

/*  current  port  which  polling  routine  starts  */ 
portno, 

/*  current  port  number  that  is  being  accessed  */ 
ro_users_.crL.sySf 

/*  number  of  users  currently  on  the  system  */ 
no_of_users, 

/*  number  of  users  that  can  access  the  system  */ 
and,  /*  code  for  user  command  type  */ 


/* 

1: 

FUN 

V 

/* 

2: 

LIST 

V 

/* 

3: 

PRINT 

V 

/* 

4: 

DEL  (Delete) 

V 

/* 

5s 

DIR  (Directory) 

V 

memoryJLoc,  /*  The  memory  location  for  a  file*/ 
fd,  /*  file  descriptor  used  on  opened  files  */ 
finished,  /*  boolean  indicating  entire  file  */ 
/*  has  been  read  */ 

size,  /*  number  of  blocks  used  by  a  file  */ 
dtrack,  /*  directory  track  to  read  */ 

dsector,  /*  directory  sector  to  read  */ 

del^track,  /*  dir  track  of  file  for  deletion  */ 
del^sector,  /*  dir  sector  of  file  for  delet.  */ 
number_jobe,/*  number  of  jobs  in  main  memory  */ 
begin_address  [MAXJCBS+1] ,  /*  beginning  ad  dr.  */ 
/*  of  each  jobs  main  memory  allocation  */ 
encLaddress  [MAXJOBS] ,  /*  end  addr.  of  each  */ 
/*  jobs  main  memory  allocation  */ 


E-6 


order [MAXJOBS+1] ;  /*  indices  of  the  sorted  */ 
/*  beginning  addr.  location*/ 

char  command_line[32J ,  /*  command  line  entered  by  */ 

/*  the  user  */ 

file_usemame  [  8]  f/ "username  of  requested  file*/ 
openecLf iles [ 4]  [32],  /*  info  of  opened  files*/ 
name  [12] ,  /*  filename  from  the  directory  */ 
file [12] ,  /*  filename  sent  from  the  user  */ 
message [MESSIZE] ;  /*  message  tobe  transnitted*/ 

/*  the  following  is  the  structure  definition  for  the  */ 
/*  command  table  which  will  be  used  through  the  validation*/ 
/*  of  the  command  and  setting  up  of  the  pcbs  */ 

struct  comm_table  { 

char  command  [  8] , 

parameterl[12] , 
parameter2[12] ; 

int  numparam; 

/*  0  =  only  a  command  */ 

/*  1  =  one  param  plus  command  */ 
/*  2  =  two  param  plus  command  */ 
/*  int  terminal;  this  may  be  used,  but  portno  */ 
/*  should  be  used  with  no  forseeable  problem  */ 
} 

commancLtable; 


/a***************************************************************/ 

/*  */ 

/*  MAIN  */ 

/*  */ 

/*  Date:  31  August  1983  V 

/*  Version:  1.0  V 

/*  V 

/*  Name:  main  */ 

/*  Module  Number:  1.2  */ 

/*  Function:  This  is  the  module  that  initializes  the  data  */ 

/*  base,  monitors  the  consoles  and  validates  the  */ 

/*  commands.  */ 


/*  Calling  Modules:  None  V 

/*  Modules  Called:  initialize_data_base ,  p_comniJLiner  */ 

/*  and  det_valid_comm  */ 

/*  V 

/*  Global  Variables  Used:  None  V 

/*  Global  Variables  Changed:  None  V 

/*  V 

/*  Author:  Paul  E.  Cruse r  and  Ronald  K.  Miller  */ 

/*  System:  VAX  11/780,  VMS  0/S  and  UNIX:  for  testing,  only  */ 

/*  */ 

/****************************************************************/ 

m?dn() 

begin 

initialize_data_base () ; 
for  (;;) 
begin 

p_ccmni_line() ; 
det_valid_conm() ; 


/****************************************************************y 


INITIALIZE  DATA  BASE 


/*  Date:  1  September  1983  */ 

/*  Version:  1.0  */ 

/*  */ 

/*  Name:  imtialize_data_base  */ 

/*  Module  Number:  1.2.1  */ 

/*  Function:  To  enter  those  initial  parameters,  that  are  */ 

/*  necessary  for  the  operation  of  the  o/s,  into  */ 

/*  the  data  base.  */ 

/*  */ 

/*  Calling  Modules:  main  */ 

/*  Modules  Called:  none  */ 

/*  V 

/*  Global  Variables  Used:  temppcb,  pcb[],  ports  [] ,  */ 

/*  userblocksEJ,  usertable[J,  */ 

/*  no_users_cr\_sys,  and  no_af_users  */ 

/*  Global  Variables  Changed:  all  of  the  ones  used  */ 

/*  */ 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  13/780,  VMS  Q/S  and  UNIX  O/S:  testing  only  */ 

/*  */ 

/****************************************************************/ 

initialize_dataLbase  {) 
begin 

int  count; 

/*  the  following  are  initialization  of  the  status  &  data  ports'  */ 
/*  addresses  and  the  masks  for  the  send  and  receive  bits  */ 

/*  ports  0-3  are  console  ports;  port  4  is  a  printer  port  */ 

ports [0] .statport  =  0; 
ports [0] .dataport  *  0; 
ports [0] .sendbit  *  0; 
ports [0] .recvbit  *  0; 
ports [lj .statport  *  0; 
ports [lj .dataport  =  0; 
ports [1] .sendbit  =  0; 
ports [1] .recvbit  =  0; 
ports [2] .statport  =  0; 
ports [2] .dataport  *  0; 
ports [2] .sendbit  *  0; 
ports [2] .recvbit  *  0; 
ports 13] .statport  =  0; 
ports [3] .dataport  ■  0; 
ports [3] .sendbit  =  0; 
ports [3] .recvbit  =  0; 
ports [4] .statport  ■  0; 
ports [4] .dataport  ■  0; 
ports [4] .sendbit  «  0; 
ports [4] .recvbit  ■  0; 


/*  when  more  ports  are  made  available,  then  they  are  to  */ 

/*  be  added  on  to  this  initialization  list  */ 

/*  the  following  is  the  initialization  of  the  status  bits  of  */ 
/*  the  userblocks  (the  structures  that  tell  the  system  who  is  */ 
/*  logged  onto  which  terminal)  */ 

/*  the  loggedon  and  jobrunning  will  both  be  initialized  to  0  */ 

count  »  0? 

while  (count  <  noports) 
begin 

userblocks [count] .loggedon  «  0; 
userblocks [count] .jobrunning  *  0; 
count  «  count  +  1; 
end 

/*  the  following  is  the  initialization  of  the  usernames  */ 

/*  and  the  passwords  */ 

strcpy (usertable [0] .username, superuser) ; 
strcpy (usertable [ 0] .password, sprpess) ; 
strcpy (usertable [l] .username, userl) ; 
strcpy (usertable [1] .password,passl) ; 
strcpy  (usertable  [2]  .username,  user  2) ; 
strcpy (usertable [2] .password, pass2) ; 

/*  etc.  V 

/*  the  following  is  the  initialization  of  the  queue  counter  for  */ 
/*  the  I/O  wait.  System,  and  Readyl  queues  */ 

iowaitq.qcount  ■  0; 
systemq.qoount  ■  0; 
readylq.qoount  ■  0; 


/*  the  following  initializations  are  for:  */ 
/*  number  of  users,  which  is  currently  3  */ 
/*  number  of  users  on  the  system,  which  is  0  V 
/*  number  of  jobs  on  the  system,  which  is  0  */ 
/*  portno,  set  to  the  first  port  -  0  */ 
/*  the  portno  will  be  changed  in  the  polling  routine  */ 
/*  the  number  of  users  on  the  system  will  change  as  the  users  */ 
/*  log  on  and  off  of  the  system  */ 


no_af_users  ■  3; 
no_use  r  s_or\_sys  ■  0: 
number_Jobe  ■  0; 
portno  ■  0; 
poli_portno  ■  0; 

/*  the  following  is  the  initialization  of  the  begin  address  */ 
/*  and  end  address  of  the  available  memory  space.  These  are  V 
/*  used  to  allocate  and  deallocate  memory  (Memory  Mgt.)  */ 


/ft***************************************************************/ 
/* 

/*  LOGIN-USER 

/* 

/*  Date:  13  September  1983 

/*  Version:  1.1 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/*  Author: 

/*  System: 

/* 


Name:  login-user 

Module  Number:  1.2 .3.1 

Function:  This  module  will  determine  if  the  user  is 
-  to  log  onto  the  system  and  then  enters  the 
his  username  into  the  userblock  table. 

Calling  Modules:  det_valicLoocm 

Modules  Called:  buildjoessage,  ge t_command_l ine ,  error, 
checkuser,  and  strcpy 

Global  Variables  Used:  userblocks [] .usernm,  portno, 

user blocks  [] .loggedon, 
no_use  r  s_on_sys , 
and  ccranand_line 

Global  Variables  Changed:  userblocks  []  .usernm  and 

no_.users_aL.sys 


Paul  E.  Cruser 

VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing,  only 


V 

V 

*/ 

V 
*/ 
*/ 

V 

V 

V 

V 

V 

V 
*/ 

V 
*/ 

V 

V 

V 

V 
*/ 

V 
*/ 
*/ 

V 

V 

V 


/********************★**************•****■*************************/ 


login_user() 

begin 

idefine  unmessage  6 

Idefine  pwmessage  7 

Idefine  illegal_user  4 

Idefine  logiiLocmplete  9 

int  i,j; 
char  un[8] , 

P#[8]; 

if  (userblocks [portno] .loggedon  «**  0) 
begin 

buildjnessage(unroessage) ;  /*  username  prompt  */ 

getL.oommaiid_J.ine  ()  ?  /*  get  the  username  from  the  user  */ 
i  »  0; 

while  (i  <  8)  /*  take  the  username  from  the  comm  line  */ 

if  (oommand_line[i]  1*  'Nn') 
un[i]  -  command_line[i] ; 
else 

begin  /*  fill  the  rest  of  un[]  with  blanks  */ 
for  (j»i77;j++) 
un[i]  »  '  •; 
i  »  87 


.  ,■*  .  *  .‘*V»  ,’v  ’ 

WaJ*  ■-*  ^ v*  4_’  ^ 
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'  .»  '.-V.  l  »  - 


buildjnessage(pwmessage)  j  /*  password  prompt  */ 
getjcommand_line() ;  /*  get  the  password  from  the  user  */ 
i  *  0; 

while  (i  <  8)  /*  take  the  password  from  the  comm  line  */ 

If  (ooranandLline[l]  1-  '\n') 
un[i]  *  ccnnand_line[i] ; 

begin  /*  fill  the  rest  of  pw[]  with  blanks  */ 
for  (j-ij7;j++) 
un  [i]  ■  '  ' ; 
i  -  8 j 
end 


if  (checkuser (un,pw) ) 

/*  check  to  see  if  user  can  get  on  system  */ 

begin 

/*  copy  the  necessary  data  into  the  next  available  */ 
/*  user  block  */ 

strcpy  (userblocks  [nojusersL.cn_.sys]  .use nan, in) ; 
userblocks  [nojusers_cn_sys]  .loggedon  *=  1; 
no_users_cn_sys  -f«  1; 
buildjnessage  (logir\_complete) ; 

return (1) j  /*  one  returned  if  login  successful  */ 
aid 
else 
begin 

/*  send  illegal  user  message  to  the  console  trying  */ 

/*  to  log  in  */ 

error ( illegaljuser ) ; 

return (0)  j  /*  zero  returned  if  login  unsuccessful  */ 
/*  ie.  wrong  password  or  invalid  user  name  */ 


aid 

end 

else 

return (2) ; 


/*  two  returned  if  login  not  necessary  */ 
/*  ie.  the  user  is  already  logged  on  */ 


•  '  V  v‘  ■ 


y A***************************************************************/ 
/* 

/*  LOGOUT-USER 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


Date:  1  September  1983 

Version:  1.0 

Name:  logout_user 
Module  Number:  1.2 .3 .2 

Function:  To  clear  the  userblock  of  the  username  and 
to  set  the  loggedon  and  jobrunning  flags  to 
'no' .  The  jobrunning  will  be  set  as  a  pre¬ 
caution. 


Calling  Modules:  det_valid_coram 
Modules  Called:  buildjnessage,  strcpy 

Global  Variables  Used:  userblocks,  portno,  and 

no_users_cr\_sys 

Global  Variables  Changed:  userblocks  and 

no_use  r  s_crL_sy s 


Author: 

System: 


Paul  E.  Cruse r 

VBX  13/780,  VMS  O/S  and  UNIX  O/S:  testing  only 


V 

V 

V 

V 

V 

V 

*/ 

V 

V 

V 

V 

V 

*/ 

V 

V 

V 

V 

V 

V 

V 
*/ 
*/ 

V 

*/ 


/****************************************************************/ 


logout_user() 

begin 

♦define  logoutmessage  8 
int  i; 

for  (i-0;7;i++) 

userblocks  (portno]  .usemn[i]  ■  1 
userblocks [portno] .loggedon  *  0; 
userblocks [portno] .jobrunning  «  0; 
no_users_on_sys  ■  no_use r s_crusys  -  1; 
buildjnessage  (logoutmessage) ; 
return  (1) ; 
end 


/****************************************************************/ 

/*  V 

/*  PARSE  COMMAND  LINE  V 

/*  V 

/*  Date:  13  September  1983  */ 

/*  Version:  1.1  */ 

/*  V 

/*  Name:  p_ccmn\_line  */ 

/*  Module  Number:  1.2.2  V 

/*  Function:  To  retrieve  the  data  line  that  is  entered  by  */ 

/*  at  a  terminal.  The  lower  case  letters  will  */ 

/*  then  be  changed  to  upper  case,  only  for  the  V 

/*  command  and  not  the  parameters  V 

/*  V 

/*  Calling  Modules:  main  V 

/*  Modules  Called:  get_comraand_line ,  build_parse_table,  */ 

/*  process_scheduler,  poll  */ 

/*  */ 

/*  Global  Variables  Used:  none  */ 

/*  Global  Variables  Used:  none  */ 


/*  Author:  Paul  E.  Cruse r  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/ft***************************************************************/ 

p_ccmm_line() 

begin 

♦define  pcocess_abort  9 
♦define  processingjdone  10 
if  (pollO ) 
begin 

getuoonmancLJLineO  ;  /*  get  comm  line  from  the  user  */ 

build_parse_table {) ;  /*  have  the  comm  line  parsed  and  */ 

/*  saved  */ 


end 

else 

if  ( Iprocessjecheduler () ) 
error  (processL.abort) ; 
else 

buildjnessage  (processing_done) ; 


y ****************************************************************/ 


/*  V 

/*  POLL  */ 

/*  V 

/*  Date:  11  October  1983  */ 

/*  Version:  1.1  */ 

/*  V 

/*  Name:  poll  */ 

/*  Module  Nunber:  1.2.2 .1  */ 

/*  Function:  To  poll  the  ports  that  the  users  consoles  */ 

/*  will  be  communicating  through.  It  will  */ 

/*  return  a  1  if  a  port  is  sending  something  */ 

/*  or  a  0  if  it  has  checked  each  port  once  and  */ 

/*  has  not  gotten  a  response  from  any  of  them  */ 

/*  V 

/*  Calling  Modules:  p_consiLj.ine  */ 

/*  Modules  Called:  none  */ 

/*  V 

/*  Global  Variables  Used:  portno,  ports  []  */ 

/*  Global  Variables  Changed:  portno  */ 

/*  V 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  */ 


/ft***************************************************************/ 

pollO 

begin 

int  pno,  /*  temporary  port  number  variable  */ 

yes,  /*  flag  to  tell  if  a  port  needs  to  be  tended  to  */ 
counter,  /*  count  how  many  ports  have  been  checked  */ 
tempstat,  /*  temp,  storage  for  the  status  ports'  contents  */ 
rstat;  /*  status  byte  masked  */ 
yes  ■  0? 
counter  ■  0; 
pno  ■  polljortno; 
while  (lyes) 

while  ((counter  <  noports)  &&  (lyes)) 
begin 

if  (userblocks  [pno]  .jobrunning  1=1) 
begin 

rstat  »  (inp(ports[pno] .statport)  &  ports [pno] .recvbit) ; 
if  (rstat  ■  0) 
begin 
yes  ■  1; 
portno  ■  pno; 
return(l) ; 
end 

else  if  (pno  “  noports-1) 
pno  ■  0; 
else 


pno  ■  pno  +  l; 


^**********h***************************************************y 

/*  v 

/*  SYSTEMjCHANGE  */ 

/*  V 

/*  Date:  3  September  1983  */ 

/*  Version:  1.0  V 

/*  V 

/*  Name:  syst  exchange  */ 

/*  Module  Number:  1.2.3.4  */ 

/*  Function:  Hiis  will  verify  that  the  user  is  authorized  */ 

/*  to  make  the  systan  changes  that  are  requested  */ 

/*  and  then  makes  those  changes  using  a  menu  */ 

/*  system,  if  a  menu  is  needed.  */ 

/*  */ 

/*  Calling  Modules:  de t_val id_comm  */ 

/*  Modules  Called:  build_pcb,  error,  adduser ,  and  deluser  */ 

/*  V 

/*  Global  Variables  Used:  superuser,  userblocks[] .username,  */ 
/*  portno  V 

/*  G1obal  Variables  Changed:  none  */ 

/*  V 

/*  Author:  Paul  E.  Cruse r  */ 

/*  Systan:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  */ 

/****************************************************************/ 

systaq_change() 

begin 

♦define  not_superuser  5 
char  *systemocmm; 

if  ( str ingcmp (superuser, userblocks [portno] .use mm) ) 
begin 

builcLpcb  (-1) ; 
systemccram  *  "ADDUSER" ; 

if  (stringcmp(systanccmm,ooinraan<i_table.parameterl) ) 
adduser () ; 
else 

begin  _ 

systancanm  =  "DELUSER"; 

if  (stringcmp(systenccmm,axnmancLtable.paraneterl) ) 
deluser () ; 

else 

begin 

/*  to  be  updated  when  other  commands  */ 

/*  are  necessary  for  the  system  */ 
aid  /*  last  else  */ 
aid  /*  previous  else  */ 
end  /*  first  if  */ 
else 

error (notjsuperuser) ; 


/****** ***********************************************************  / 


/*  HELP-USER  */ 

/*  */ 

/*  Date:  3  September  1983  */ 

/*  Version:  1.0  */ 

/*  V 

/*  Name:  helpjuser  */ 

/*  Module  Number:  1.2.3 .3  */ 

/*  Function:  Hus  checks  to  see  if  the  help  can  be  pro-  */ 

/*  vided  and  gives  out  the  information  or  a  */ 

/*  message  is  sent  to  the  user  that  no  info  is  */ 

/*  available.  */ 

/*  V 

/*  Calling  Modules:  det_valid_cornm  */ 

/*  Modules  Called:  buildjnessage,  stringcmp,  users__a\_J.ine  */ 

/*  and  devices_available  */ 

/*  */ 

/*  Global  Variables  Used:  portno,  usertable  */ 

/*  Global  Variables  Changed:  none  */ 

/*  V 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/A***************************************************************/ 

help_user() 

begin 

♦define  no_help  0 

♦define  run-format  1 

♦define  listJEormat  2 

♦define  print-format  3 

♦define  delete _format  4 

♦define  direct ory_format  5 
int  help_set; 

char  *users , *devices , *run , *list , *print , *delete, *directory ? 

users  »  "USERS";  /*  request  to  list  the  users  on  the  system  */ 

devices  »  "DEV";  /*  request  to  list  the  devices  on-line  */ 

run  »  "RUN";  /*  req.  to  shew  the  format  for  run  canm.  */ 

list  ■  "LIST";  /*  req.  to  show  the  format  for  list  comm.  */ 


print  ■  "PRINT" 
delete  *  "DEL";  /*  req.  to  shew  the  format  for  delete  comm, 
directory  *  "DIR";  /*  req.  to  show  the  format  for  dir.  comm. 
help_set  »  0; 

if  (stringcmp (users, ccranand_table. parameter!) ) 

belp_set  ■  1;  /*  system  inquiry  */ 
else 

if  (stringcnp(devices,ccramancLtable.paraneterl) ) 
help_set  «  2;  /*  system  inquiry  */ 
else 

if  (stringcmp(nm,oommand_table. parameter!) ) 
help_set  »  3;  /*  command  inquiry  */ 


"PRINT";  /*  req.  to  show  the  format  for  print  comm. 


if  (stringcmp(list,command__table.parameterl) ) 
help_.se t  =  4;  /*  command  inquiry  */ 
else 

if  ( st r ingcmp  (print,  commancLtable .  pa  r aneter  1 ) ) 
help_.se t  =  5;  /*  command  inquiry  */ 
else 

if  (stringarp(deletefcoramancLtable.parameterl) ) 
help_.se t  =  6;  /*  command  inquiry  */ 
else 

if  (stringcmp(directory,coromand_table.paraneterl) ) 
help_set  =7;  /*  command  inquiry  */ 
switch  (help_.se  t) 
begin 

case  0:  buildjnessage (no_help) ; 
case  Is  users_crOLine 0  ; 
case  2  s  devices__available() ; 
case  3:  buildjnessage  (run_format) ; 
case  4:  buildjnessage  (list_format) ; 
case  5:  buildjnessage  (print_format) ; 
case  6s  buildjnessage (delete_format) ; 
case  7  s  buildjnessage  (direct ory_f orma t) ; 
defaults  buildjnessage  (nojbelp) ; 


/ ****************************************************************/ 

/*  V 

/*  ADDUSER  V 

/*  V 

/*  Date:  7  September  1983  V 

/*  Version:  1.0  */ 


/*  Name:  adduser  V 

/*  Module  Nisnber:  1.2.3.4.2A  */ 

/*  Function:  Adds  a  new  user's  username  and  password  */ 

/*  V 

/*  Calling  Modules:  systenuchange  */ 

/*  Modules  Called:  none  */ 

/*  V 

/*  Global  Variables  Used:  no_of_users,  user  table  */ 

/*  Global  Variables  Changed:  no_of_users,  user  table  */ 

/*  */ 

/*  Author:  Paul  E.  Cruse r  */ 

/*  System:  VAX  11/780,  VMS  O/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/*******★********************************************************/ 

adduser () 
begin 

♦define  blank  '  ' 
int  cit; 

no_of_users  4*  1; 
cnt  »  0; 
while  (cnt  <»  7) 
begin 

cnt  4«=  1; 

/*  read  in  the  username  into  */ 

/*  user  table  [no_of_users-l]  .username  */ 
end 

cnt  *  0; 

while  (cnt  <=  7} 
begin 

usertable  [no_of__users-l]  .password  [cnt]  =  blank; 
cnt  4*=  l: 


/****************************★***********************************/ 


/* 

V 

/* 

DELUSER 

V 

/* 

V 

/* 

Date:  7  September  1983 

V 

/* 

Version:  1.0 

V 

/* 

V 

/* 

Name:  deluser 

V 

/* 

Module  Number:  1.2.3.4.2B 

V 

/* 

Function:  Delete  a  user's  username  and  password  from 

*/ 

/* 

the  usertable 

V 

/* 

*/ 

/* 

Calling  Modules:  systenuchange 

V 

/* 

Modules  Called:  none 

*/ 

/* 

V 

/* 

Global  Variables  Used:  no_of_users ,  usertable 

V 

/* 

Global  Variables  Changed:  no_of_jusers,  usertable 

V 

/* 

V 

/* 

Author:  Paul  E.  Cruser 

V 

/* 

System:  VAX  13/780,  VMS  O/S  and  UNIX  O/S:  testing  only 

V 

/* 

*/ 

/****************************************************************/' 

deluser () 
begin 

int  cont,i, j? 
char  deletenarne  [  8] ; 

/*  read  deletenarne  from  superuser  */ 
for  (cont  *  l;no_of_users-l;cont++) 

if  (stringcmp (user table [cont] . username, deletenarne) ) 
i  *  cont; 

for  (cont  *  i jno_of_users-2?cont++) 

/*  shift  the  table  down  over  the  user's  id  */ 
begin 

for  (j  *  0;7; j++) 
begin 

usertable  [cont]  .username  [  j]  = 

usertable[cont+l]  .username [j] ; 
usertable [cont] .password [ j] = 

usertable [cont+lj .password [j] ; 
end 
end 


no  of  users  -=  1; 


/♦♦♦♦♦A**********************************************************/ 
/* 

/*  DSERS_CN_JJNE 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


Date:  9  September  1983 
Version:  1.0 

Nane:  users_cn JLine 
Module  Number:  1.2.3.3.1A 

Function:  Lists  the  users  that  are  logged  into  the 

system  and  the  terminals  they  are  using 


Calling  Modules: 
Modules  Called: 


help_user 

transroitjnessage 


Global  Variables  Used:  noports,  userblocks,  MESSIZE 
Global  Variables  Changed:  none 


Author: 

System: 


Paul  E.  Cruser 

VAX  13/780,  VMS  Q/S  and  UNIX  O/S:  testing  only 


*/ 

V 

V 

V 

V 

V 

V 

*/ 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 


/****************************************************************/ 


users_onJLine  () 
begin 

int  duke,i; 

char  terminal [MESSIZE  -  10] ;  _ 

strcpy (terminal,"  TERMINAL  ") ; 

for  (duke  =  0;noports  -  l;duke4+) 
if  (userblocks [duke] .loggedon) 
begin 

for  (i  =  0;7;i++) 

message  [i]  ■  userblocks  [duke]  ,usemm[i]; 
for  (i  =  0;MESSIZE  -  10;i++) 
message [i+7]  »  terminal [i] ; 
switch (duke) 
begin 

case  0:  {  message [MESSIZE- 2]  *  "0";  break;  } 

case  1:  {  message [MESSIZE-2]  ■  "1";  break;  } 

case  2:  {  message [MESSIZE-2]  =  "2";  break;  } 

case  3:  {  message [MESSIZE-2]  =  "3";  break;  } 

message [MESSIZE-1]  -  "\n"; 
transraitjnessage  (message) ; 


r. .  --.v 


/****************************************************************/ 

/*  V 

/*  DEVICES_JWAILABLE  */ 

/*  V 

/*  Date:  9  Septanber  1983  */ 

/*  Version:  1.0  */ 

/*  V 

/*  Name:  devices_available  */ 

/*  Module  Number:  1.2 .3 .3 .IB  */ 

/*  Function:  To  list  the  devices  that  are  online  */ 


Calling  Modules: 
Modules  Called: 


help_user 

transmit_message 


/*  Cobal  Variables  Used:  device_table,  MESSIZE  */ 

/*  Global  Variables  Changed:  none  */ 

/*  */ 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  11/780,  VMS  Q/S  and  UNIX  O/S:  testing  only  */ 

/*  */ 

/****************************************************************/ 

devices_available  () 
begin 

/*  will  be  written  later  */ 

/*  it  will  be  the  same  as  */ 

/*  users_cr\_line  in  structure  */ 
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/****************************************************************/ 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


BUILD_MESSAGE 

Date:  9  September  1983 
Version:  1.0 

Name:  buildjnessage 
Module  Number:  1.2.3 .1.2 

Function:  To  build  a  message  to  be  sent  to  the  user 
by  using  a  integer  code  sent  in  to  indicate 
what  message  is  needed. 


Calling  Modules: 
Modules  Called: 


login_user ,  logout_user ,  helpjuser 
trananitjnessage 


Global  Variables  Used:  message/  MESSIZE 
Global  Variables  Changed:  message 


Author: 

System: 


Paul  E.  Cruse r 

VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only 


V 

V 

V 

V 

*/ 

*/ 

V 

V 

V 

V 
*/ 

V 
*/ 

V 
*/ 

V 
*/ 

V 

V 
*/ 

V 


/****************************************************************/ 

buildjnessage  (coded) 
int  coded; 
begin 

char  codeO  [MESSIZE]  ,oodel  [MESSIZE]  ,oode2  [MESSIZE]  ,oode3  [MESSIZE] , 
code4  [MESSIZE] , codes  [MESSIZE]  ,COde6  [MESSIZE]  ,code7  [MESSIZE]  , 
code  8  [MESSIZE]  foode9  [MESSIZE]  ,codel0  [MESSIZE]  ; 
strcpy (codeO, "No  help  is  available  for  that  command  Nn"); 
strcpy(codel /"Format:  RUN  FILENAME  (executable  file)  \n"); 


strcpy (code2, "Format:  LIST  FILENAME 
strcpy(code3, "Format:  PRINT  FILENAME 
strcpy (code 4 , "Format :  DEL  FILENAME 
strcpy  (oode5 ,  "Format :  DIR 
strcpy  (code€ , "USERNAME : 
strcpy (code7 , "PASSWORD: 
strcpy (code8, "Logged  out... 
strcpy (code9, "Log-in  complete.., 


strcpy (codelO, "Processing  of  job  complete... 
switch(coded) 


Vi")7 

(nonexecutable)  \n") ; 

Nn"); 

\h")7 

Nn"); 
Nn"); 
Nn"); 
Nn"); 
Nn"); 


begin 

case  0:  {  strcpy (message, codeO) ;  break;  } 
case  1:  {  strcpy (message, oodel) ;  break;  } 
case  2:  {  strcpy (message, code2) ;  break;  } 
case  3:  {  strcpy (message, oode3 ) ;  break;  } 
case  4:  {  strcpy(message,code4) ;  break;  } 
case  5:  {  strcpy (message fcode5) ;  break;  } 
case  6:  {  st rcpy( message, code6 ) ;  break;  } 
case  7:  {  strcpy (message, code7) ;  break;  } 
case  8:  {  strcpy (message, code 8) ;  break;  } 


case  9s  {  strcpy (message, code9) ;  break?  } 
case  10:  {  strcpy (message, codelO) ?  break?  } 
default:  {  error (6)?  return (0) ?  } 
end 

transmit_message (message) ; 
return (1) ; 


^  *1  ■  \ F  a  ■ 


y'****************************************************************/' 

/*  V 

/*  BUILD_PCB  */ 

/*  V 

/*  Date:  13  September  1983  */ 

/*  Version:  1.0  */ 

/*  V 

/*  Name:  builcLpcb  */ 

/*  Module  Number:  1.2.3. 5. 2.1.2  */ 

/*  Function:  To  initialize  a  pcb  for  a  job/process  to  */ 

/*  be  run  or  put  on  a  queue  */ 

/*  V 

/*  Calling  Modules:  get_file,  syst  exchange  */ 

/*  Modules  Called:  insert_pcb  */ 

/*  V 

/*  Global  Variables  Osed:pcb[] ,  userblock[] ,  and  portno  */ 

/*  Global  Variables  Changed:  pcb[]  */ 

/*  V 

/*  Author:  Paul  E.  Cruse r  */ 

/*  System:  VAX  11/780,  VMS  Q/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/****************************************************************/ 

builcLpcb ( jobcode) 
int  jobcode; 

/*  note:  if  there  is  another  ready  queue  added,  then  another  */ 

/*  parameter  would  be  passed  in  to  give  the  priority  */ 


begin 

pcb  [portno]  .port_ofL_origin  “  portno? 
pcb [portno] .io_status  »  1; 
if  (jobcode  —  -1) 

begin  /*  if  it  is  a  SYS  command  */ 
pcb [portno] .priority  ■  0?  /*  this  is  where  the  second  */ 

/*  parameter  would  be  used  */ 
pcb [portno] ,current_q  =  0?  /*  but  not  here,  since  it  */ 

/*  will  always  be  0  for  SYS  */ 
pcb  [portno] .io_status  »  0;  /*  only  for  SYS:  it  will  */ 

/*  not  have  to  wait  for  i/o  */ 
/*  until  time  to  write  to  */ 
/*  data  base  on  disk-  which  */ 
/*  is  not  being  coded  in  */ 
/*  this  version  of  AMDS  */ 
pcb  [portno]  .commancLtype  ■  jobcode; 
mid 

else  /*  else  it  is  something  else  */ 
begin 

pcb  [portno]  .priority  -1;  /*  this  is  where  the  second  */ 

/*  parameter  would  be  used,  */ 
pcb  (portno]  .current^  -  1 ;  /*  as  well  as  here  */ 

pcb  [portno]  .commancLtype  *  jobcode; 


y ************ ****************************************************/ 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/**■. 


GETJEMMEND _JJNE 

Date:  13  September  1983 
Version:  1.0 

Name:  get_ccmancLline 
Module  Number:  1.2 .2. 2 

Function:  To  read  in  a  line  frcm  the  user's  port 

Calling  Modules:  p_cornmand_line ,  loginjuser 
Modules  Called:  getcharO  ,  inp() 

Global  Variables  Used:  commancLline ,  ports [] ,  portno 
Global  Variables  Changed:  commandJLine 


Author: 

System: 


Paul  E.  Cruse r 

VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only 


*/ 

V 

V 

V 

V 

*/ 

V 

V 

V 

V 

V 
*/ 
*/ 

V 

*/ 

V 

*/ 

V 

V 


*************************************************************/ 


get_command_line () 

begin 

int  q; 

q  ■  0; 

while  ( (q<31)  && ( (commandJLine [q]  =  getcharO)  1=  'Nn')) 
begin 

q  *  q  +  1;  /*  read  in  the  command  line  */ 

while  ((inp(portstportno]  .statport)  & 

ports  [portno]  .recvbit)  =0); 
end 


/*  note: 

getchar  will  not  be  the  library  routine 

V 

/* 

it  will  have  to  worry  about  what  port  to 

*/ 

/* 

receive  the  response.  The  getchar  routine 

V 

/* 

will  be  replaced  by  inp(portaddress) , 

V 

/* 

where  portaddress  is  taken  from  the  ports 

*/ 

/* 

table. 

V 

if  (q  »  31)  conmand_line[31]  »  'Nn'? 

/*  make  sure  there  is  a  carriage  return 


return (1) ; 
end 


V 


/♦♦♦♦a***********************************************************/' 


/*  V 

/*  CHECKUSER  */ 

/*  V 
/*  Date:  13  September  1983  */ 
/*  Version:  1.0  */ 

/*  V 
/*  Name:  checkuser  */ 
/*  Module  Number:  1.2 .3 .1.1 .3  */ 
/*  Function:  To  see  if  the  user  is  logged  onto  the  system  */ 
/*  The  value  1  is  returned  if  not  else  0  */ 
/*  */ 
/*  Calling  Modules:  logiruuser  */ 
/*  Modules  Called:  stringcrap  */ 

/*  V 
/*  Global  Variables  osed:  usertable[]  f  noports  */ 
/*  Global  Variables  Changed:  none  */ 

/*  V 
/*  Author:  Paul  E.  Cruser  */ 
/*  System:  VAX  13/780,  VMS  O/S  and  UNIX  O/S:  testing  only  */ 
/*  V 


/ft***************************************************************/ 

checkuser  (unm,pwd) 
char  unm[8]  ,pwd[8]; 
begin 

int  no,  counters; 

no  «*  1;  /*  flag  to  indicate  if  username  was  found  */ 
counters  *  0;  /*  step  counter  for  the  usertable  */ 
while  ( (no)  &&  (counters  <  noports)) 
begin 

if  (stringcmp (usertable [counters]  .username, vam) ) 
no  «  0; 

if  (no)  counters  +*  1; 
end 

if  ((Ino)  &&  (counters  <  noports)) 

if  (stringcmp (usertable [counters] .password,pwd) ) 
return (1) ; 


return (0) ; 


/****************************************************************/ 
/*  */ 

/*  INSERT_PCB  */ 

/*  V 

/*  Date:  15  September  1983  */ 

/*  Version:  1.1  */ 

/*  */ 

/*  Name:  insert _pcb  */ 

/*  Module  Number:  1.2.3 .5. 2. 1.2.1  */ 

/*  Function:  To  insert  a  process  control  block  into  a  */ 

/*  queue.  The  queue  is  determined  by  the  */ 

/*  priority  that  was  set  when  the  pcb  was  */ 

/*  initializes.  */ 

/*  V 

/*  Calling  Modules:  builcLpcb  */ 

/*  Modules  Called:  none  */ 

/*  */ 

/*  Global  Variables  Used:  pcb  [I,  systemq,  readyq,  iowaitq  */ 

/*  Global  Variables  Changed:  systemq,  readyq,  iowaitq  */ 

/*  V 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  10/780,  VMS  O/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/a***************************************************************/ 

insertupcbO 

begin 

if  ( Ipcb[portno] ,io_status) 
switch  (pcb  [portno]  .priority) 
begin 
case  0: 

/*  insert  into  the  systemq  */ 
begin 

if  (systemq.qoount  «*  0) 
begin 

/*  systemq. start  ■  pcb  [portno] ; 
systemq. ending  =  pcb  [portno] ; 
pcb  [portno]  .nextL_cb  =  pcb  [portno] ; 
pcb  [portno]  .previous_cb  =  pcb  [portno]  ;*/ 
end  /*  if  */ 
else 
begin 

/*pcb  [portno]  .nextjcb  =  systemq.  start; 
pcb [portno] ,previous_cb  =  systenq .  aiding . ne xt_cb  ? 
systemq.  ending.  next_cb  =  pcb  [portno]; 
systsnq.  aiding  =  pcb  [portno]; 
systsnq.start.previous_cb  =  syst  an.  aiding;*/ 
end  /*  else  */ 
systemq.qoount  +«  1; 


end  /*  case  0  */ 
case  1: 

/*  insert  into  the  readylq  */ 
begin 

if  (readylq.qoount  =  0) 
begin 

/♦readylq.  start  «=  pcb[portno]? 
readylq.  aiding  =  pcb[portno] ; 
pcbtportno] ,next_cb  =  pcb[portno] ; 
pcbtportno] ,previous_cb  =  pcb[portno] ;*/ 
end  /*  if  */ 
else 
begin 

/*pcb[portno] ,next_cb  =  readylq. start; 
pcbtportno] ,previous_cb  =  readyq. ending; 
readylq.  ending.  next_cb  =  pcbtportno]; 
readylq.  ending  =  pcbtportno]; 
readylq. start. previous_cb  =  readylq.  ending;*/ 
aid  /*  else  */ 
readylq.qoount  1; 
break; 

end  /*  case  1  */ 

/*  case  2:  this  will  be  for  expansion,  ie.  */ 

/*  if  another  ready  queue  (ready2q)  */ 

/*  were  needed  and  implemented  */ 

aid  /*  switch's  begin  */ 

else 

begin 

/*  insert  into  the  icwaitq  */ 

if  (icwaitq.qcount  =■*  0) 
begin 

/♦iowaitq. start  *  pcbtportno]; 
iowaitq.  ending  =  pcbtportno]; 
pcbtportno]  .next^cb  =  pcbtportno]; 
pcbtportno] .previous_cb  =  pcbtportno];*/ 
end  /*  if  */ 

else 

begin 

/*  pcbtportno] .next_cb  =  icwaitq.  start; 

pcbtportno] ,previous_cb  =  iowaitq. ending; 
icwaitq. ending. next_cb  =  pcbtportno] ; 
iowaitq. ending  =  pcbtportno]; 
iowaitq. star t.previous_cb  «  pcbtportno];*/ 
end  /*  else  */ 


E-32 


/ ********************** ************************* *****************y 

/*  V 

/*  PROCESS_SCHEDULER  */ 

/*  V 

/*  Date:  11  October  1983  */ 

/*  Version:  1.1  */ 

/*  */ 

/*  Name:  process_scheduler  */ 

/*  Module  Number:  1.2 .3 .5. 2. 2  */ 

/*  Function:  To  process  the  I/O  wait  queue,  get  the  */ 

/*  get  the  next  reedy  process  by  checking  */ 

/*  the  system  queue  for  a  process,  then  if  */ 

/*  none  check  the  ready  queues.  If  one  */ 

/*  of  the  queues  has  a  ready  process  then  */ 

/*  the  process  is  taken  off  the  queue  and  */ 

/*  executed.  */ 

/*  */ 

/*  Calling  Modules:  execute_command  */ 

/*  Modules  Called:  send_file,  write,  process_iowaitq,  */ 

/*  check_readyqs,  get_pcb,  program_run,  */ 

/*  run_sys_ccmm,  deallocate_space  */ 

/*  */ 

/*  Global  Variables  Used:  portno  */ 

/*  Global  Variables  Changed:  portno  */ 

/*  V 

/*  Author:  Paul  E.  Cruse r  */ 

/*  System:  VAX  11/780,  VMS  O/S  and  UNIX  O/S:  testing  only  */ 

/*  */ 

/a***************************************************************/ 

process_scheduler ( ) 
begin 

Idefine  canmand_type_er r o r  10  /*  code  for  error  received  */ 

int  next_process; 
process_iowaitq() ; 
next_process  =  check_readyos() ; 
switch  (nextjprocess) 
begin 
case  -1: 
return (1) ; 

case  0: 
begin 

getLpcb  (nextjprocess) ; 
run_sys_comm() ; 
return (1) ; 
end 


case  1: 

/*  case  2:  */ 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANDARDS-1963-A 


get_pcb  (next^_pcocess) ; 
switch  (pcb  [portno]  .cxxnrrvand_type) 
begin 

case  0:  {  progran_run() ;  break;  } 
case  1: 

case  4:  {  send_file (portno) ;  break;  } 
case  2s  {  sencLfile (noports);  break;  } 
case  3s  {  write (portno) ;  break;  } 
defaults  {  error  (ocranan(L.type_error) ;  retum(O) ;} 
end  /*  switch  */ 
deallocate_space (portno) ; 
return(l) ; 


/****************************************************************/ 

/*  V 

/*  CHBOU^EflDYQS  */ 

/*  V 

/*  Date:  14  September  1983  V 

/*  Version:  1.0  V 

/*  V 

/*  Name:  check_readyqs  V 

/*  Nodule  Number:  1.2.3.5.2.2.2.1  */ 

/*  Function:  To  check  all  the  ready  queues  to  see  if  */ 

/*  there  are  any  processes  on  them.  It  checks  */ 

/*  the  queues  in  order  of  priority  and  when  */ 

/*  the  first  non  empty  queue  is  found  its  */ 

/*  priority  is  sent  back  to  the  caller.  If  */ 

/*  all  of  the  queues  are  empty  the  value  -1  is  */ 

/*  returned.  V 

/*  V 

/*  Calling  Modules:  processuscheduler  V 

/*  Nodules  Called:  none  V 

/*  V 

/*  Global  Variables  Used:  pcb[] ,  systemq,  readylq  V 

/*  Global  Variables  Changed:  none  V 

/*  */ 

/*  Author:  Paul  E.  Cruser  V 

/*  System:  VAX  U/780,  VMS  (VS  and  UNIX  O/S:  testing  only  */ 


chec<_readyqs() 

begin 

if  (systemq.qoount  >  0) 

return  (0) ;  /*  systemq  has  at  least  one  process  */ 
else 

if  (readylq.qoount  >  0) 

retum(l) ;  /*  readylq  has  at  least  one  process  */ 

/*  else  */ 

/*  if  (ready2q.qoount  >  0)  V 

/*  return(2) /  V 

/*  etc...  V 

else 

return  (-1) ;  /*  all  the  queues  are  empty  */ 


/A***************************************************************/ 

/* 

V 

/* 

GE3LPCB 

V 

/* 

V 

/* 

Date:  15  September  1983 

V 

/* 

Version:  1.1 

V 

/* 

V 

/* 

Name:  get_pcb 

V 

/* 

Module  Nunber:  1.2.3.5.2.2.2 

V 

/* 

Function:  To  get  the  next  pcb  and  take  it  off  the 

V 

/* 

queue  which  it  is  on.  The  next  pcb  is  the 

V 

/* 

first  one  on  the  queue. 

V 

/* 

V 

/* 

Calling  Modules:  process_scheduler 

V 

/* 

Modules  Called:  none 

V 

/* 

V 

/* 

Global  Variables  Used:  systanq,  readylq,  portno 

V 

/* 

Global  Variables  Changed:  systanq,  readylq,  portno 

V 

/* 

V 

/* 

Author:  Paul  E.  Cruser 

V 

/* 

System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only 

V  I 

get_pcb  (tyrone) 
int  tyrone; 
begin 
int  i; 

struct  z8pcb  *tanp; 
switch (tyrone) 
begin 
case  0: 
begin 

portno  -  systanq. start. port_of_origin; 
if  (systenq.qoount  1) 
systanq.  qoount  —  1; 
else 
begin 

tonp  ■  systanq. start; 
systanq. start  -  tanp.nextjcb; 
8ystanq.8tart.previouq_cb  - 

tanp.prwiousj±>.previous_cb; 
systonq.qoount  —  1; 
end 
break; 

end  /*  case  0  V 

case  1; 
begin 

portno  -  readylq.port_of_ocigin; 
if  (rsadylq.qoount  —  1) 
begin 
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readylq.  start  «  0; 
readylq. ending  *  0; 
readylq.  qoount  -*1} 
end 
else 
begin 

tanp  ■  readylq. start; 
readylq.  start  *  tanp.nextL.cb; 
readylq.pcevious_cb  - 

temp,  pc  eviou£L_cb .  pr  evious_cb  ; 
readylq.qoount  —  1; 
end 
break; 

end  /*  case  1  */ 
end  /*  switch  */ 


***************************************************************/ 

V 

PRj0CES5_I0WArrQ  */ 

V 

Date:  15  September  1983  */ 

Version:  1.0  */ 

V 

None:  procesg_iowaitq  */ 

Module  Number:  1.2.3.5.2.2.1  */ 

Function:  To  transfer  any  process  on  the  wait  queue  */ 

that  Is  done  with  i/o  wait  to  a  ready  queue  */ 

V 

Calling  Modules:  procesqjscheduler  */ 

Modules  Called:  insertjpcb  */ 

V 

Global  Variables  Used:  iowaitq,  noports,  portno  */ 

Global  Variables  Changed:  iowaitq  */ 

V 

Author:  Paul  E.  Cruse r  */ 

System:  VAX  11/780,  VMS  C/S  and  UNIX  o/S:  testing  only  */ 


prooes&uLowaitq  () 
begin 

int  i,tempportno; 
struct  zSpcb  *temp; 

if  (iowaitq.qoount  >  0) 
begin 

temp  ■  iowaitq. start; 
i  -  0; 

while  (i  <  noports) 
begin 

if  ( temp.  io_status  ™  0) 
begin 

tempportno  ■  portno; 
portno  -  tenp.port_of_origin; 
temp.next_cb.previous_cb  »  temp. pr evious_cb ; 
tenp.previous_cb.next_cb  -  temp.next_cb; 
iowaitq.qoount  —  1; 
insertupcbO ; 
portno  ■  tempportno; 
return  (1) ; 
end  /*  if  V 
i  +-  If 

end  /*  while  */ 
return (1) ; 
end  /*  if  */ 
end  /*  processJLowaitq  V 


/♦★♦♦a***********************************************************/ 

/*  */ 

/*  CLEML-OP  */ 

/*  */ 

/*  Date:  15  September  1903  V 

/*  Version:  1,0  V 

/*  V 

/*  Kane:  cleanjj?  V 

/*  Nodule  Umber:  00  V 

/*  Function:  This  subroutine  will  delete  any  process  V 

/*  from  the  queue  it  resides  in  and  end  it  */ 

/*  without  finishing.  It  is  not  used  in  this  */ 

/*  implementation,  but  can  be  useful  later.  V 

/*  V 

/*  Calling  Nodules:  none  V 

/*  Nodules  Called:  deallocate_space  */ 

/*  */ 

/*  Global  Variables  Used:  pcb[] ,  portno,  iowaitq,  systemq  */ 

/*  readylq  */ 

/*  Global  Variables  Changed:  iowaitq,  systemq,  readylq,  */ 

/*  pcb[]  V 

/*  */ 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/♦♦A*************************************************************/ 


clear\_tp() 

begin 

pda  [portno]  .next_cb.pcevious_cb 
pcb  [portno]  .previous_cb.nextL.cb 
deallocatejBpace  (portno) ; 
switch  (pcb  [portno]  ,current_q) 
begin 

case  -1:  {  iwaitq.qoount  -* 
case  0:  {  systemq.  qoount  -* 
case  1:  {  readylq.  qoount  — 
/*  case  2:  {  ready2q.qoount  — 
/*  etc... 

default:  retum(O); 
end  /*  switch  V 
end  /*  cleanjup  V 


pcb  [portno]  .previousjcb; 
pcb  [portno]  .next_cbf 


1;  return(l);  } 
1;  return(l);  } 
1;  return(l) ;  } 
1;  return(l);  } 


FDIUSXSLGDMM 


/*  Date:  15  September  1983  */ 

/*  Version:  1.0  V 

/*  V 

/*  Name:  run_sys_ocnm  */ 

/*  Module  Number:  1.2 .3 .4.2  */ 

/*  Function:  To  rtn  the  system  command  */ 

/*  V 

/*  Calling  Modules:  processjscheduler  */ 

/*  Modules  Called:  none  */ 

/*  V 

/*  Global  Variables  Used:  none  */ 

/*  Global  Variables  Changed:  none  */ 

/*  */ 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  */ 

/♦♦a*************************************************************/ 

runjRyq_oomm() 

begin 

/*  The  system  oonmands  are  run  in  the  module  systemjehange  */ 

/*  and  do  not  need  to  be  run  here.  This  module  will  be  needed  */ 
/*  when  the  systenuchange  will  be  actually  implemented  on  the  */ 

/*  host  micro-system.  */ 

retum(l) ; 


\  ' 


M 


/****************************************************************/ 

/*  V 

/*  PROGRAMJJJN  */ 

/*  V 

/*  Date:  15  Septenber  1983  */ 

/*  Version:  1.0  */ 

/*  V 

/*  Name:  progran_run  */ 

/*  Nodule  Nudber:  1.2 .3 .5 .2 .2 .3 .4  */ 

/*  Function:  This  routine  will  call  a  Z800  Assembly  sub-  */ 

/*  routine  that  will  enable  the  interrupts  and  */ 

/*  start  execution  of  the  file  pointed  to  by  */ 

/*  pcb’s  offset  address.  */ 

/*  V 

/*  Calling  Modules:  proces&_scheduler  * ' 

/*  Nodules  Called:  amoskemel  V 

/*  V 

/*  Global  Variables  Used:  pcb[] ,  portno  */ 

/*  Global  Variables  Changed:  none  */ 

/*  V 

/*  Author:  Paul  E.  Cruser  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 


pcogram_run  () 
begin 

if  (anoekemel  (pcb  [portno]  .off set^address, 

pcb  [portno]  .final_address) ) 

return  (1) ; 
else 

return(O) ; 
end 


.v.v.v.v: 


***************************************************************/ 

V 

DETLVRLIDjaDMM  */ 

V 

Date:  1  Sept  1983  V 

Version:  1.2  */ 


None:  det_val ieLcccm  */ 

Module  Nunber:  1.2.3  V 

Function:  This  module  will  detrmine  the  conmand  the  user  */ 
is  requesting  then  will  call  the  necessary  */ 

routines  to  have  the  specific  conmand  executed.*/ 

V 

Calling  Modules:  main  V 

Modules  Called:  log_iiuiser,  stringcmp,  log_out_userf  */ 

helpjuser,  systenuchange,  use r_conmand ,  */ 

execut  e_use  r_ooranand ,  er  ror  */ 

V 

Global  Variables  Used:  conmand_table. command  */ 

Global  Variables  Changed:  None  */ 

V 

Author:  Ranald  K.  Miller  */ 

System:  VAX  11/780,  VMS  O/S  and  UNIX  O/S:  testing  only  */ 


de  t_val  id_ooran  ( ) 
begin 

char  *bye,*help,*system;  /*  Initialize  < 
bye  *  "BYE*; 
help  »  "HELP"; 
system  ■  "SYS”; 

if (log_injuser()  1*2)  retum(l); 
if  (stringcap  (bye, aonmand_table.  command)) 
begin 

logjout_UBer() ; 
return  (1) ; 
end 

if  (stringcii9(helprcamnand_table.coinmBnd) ) 
begin 

helpjuserO ; 
return(l) ; 


/*  Initialize  comparision  string  */ 


if  (stringcmp  (system,  ootroandLtable.  command)) 
begin 


return(l) ; 

end 


• 


if  (user_ccranand  () ) 
begin 

execut  q_use  r_oornmand  ( ) ; 
return (1) ; 
end 


error (1) ; 


/A***************************************************************/ 


USERjQOMMBND 


Date:  1  Sept  1983 
Version:  1.0 


Name:  user_conmand  */ 

Nodule  Nuaber:  1.2.3B  */ 

Function:  Ibis  nodule  determines  if  the  command  */ 

requested  is  a  user  command.  */ 

V 

Calling  Nodules:  de t_val icLooran  */ 

Nodules  Called:  stringcmp  */ 

*/ 

Global  Variables  Used:  command_table . command ,  and  */ 

Global  Variables  Changed:  and  */ 

V 

Author:  Ronald  K.  Miller  */ 

System:  VAX  IV 780,  VMS  C/S  and  UNIX  O/S  :  testing  only  */ 

V 


user_ooomand() 

begin 

char  *run , *list , *pr int , *delete , *di rectory ; 

/*  Initialize  comparision  */ 
/*  strings  */ 

nn  «  "RUN"; list  -  "LIST";  print  -  "PRINT"; 
delete  -  "DEL"; directory  -  "DIR"; 
if  ( st  r  ingcrap  ( run ,  oommancLtable .  command ) ) 
begin 

and  «  1;  return(l) ;  /*  and-1  implies  run  command  */ 

aid 

if  (stingcmp(list,  oommand_table.  command)) 
begin 

and  ■  2;  return  (1) ;  /*  cmd«2  implies  list  command  */ 

aid 

if  (stringcmp  (print  rcommand_table. command)) 
begin 

and  -  3;  return (1) ;  /*  cn»d-3  implies  print  command  */ 

end 

if  (stringcmp (delete, oommand_table. command) ) 
begin 

and  *  4;  return  (1);  /*  cmd»4  implies  delete  command  */ 


if  (stringcnp  (directory  fooranarK^_table.cxxnmand) ) 
begin 

end  =  5;  return (1);  /*  crod=5  implies  directory  command  */ 

end 

return(O);  /*  return(O)  implies  not  a  user  */ 

/*  command  */ 


/A***************************************************************/ 

/*  STRINGCMP 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


Date:  1  Sept  1983 
Version:  1.0 

Name:  stringcrap 
Module  Number:  1.2.3A 

Function:  Determines  lexicographic  equality  of  two 
strings. 

Calling  Modules:  de t_val id_ocomand ,  user_coranand 
Modules  Called:  None 

Global  Variables  Used:  None 
Global  Variables  Changed:  None 

Author:  Ronald  K.  Miller 

System:  VAX  11/780,  VMS  O/S  and  UNIX  O/S:  testing  only 


V 

V 

V 

V 

V 

V 

V 
*/ 

V 

V 

V 

V 

V 

V 
*/ 

V 
*/ 

V 

V 

V 


/ft***************************************************************/ 


stringcmp(s,t) 
char  s[]  ,t[]; 
begin 
int  i, j; 
i  *  j  *  0? 

while  (s[i4+]  —  t[j++l) 

/*  Continue  while  strings  are  equal  */ 
/*  Return  (1)  if  strings  are  equal  */ 
if (s[i]  —  'XO')  return (1) ; 
return  (0) ; 
end 


.aV* 

& 


/ft***************************************************************/ 


G0 


/* 

/* 

/* 

/* 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 


EXEC^JJSEILOOMMRND 

Date:  1  Sept  1983 
Version:  1.0 

Name:  execute_user_ccranand 
Module  Number:  1.2.3 .5 

Function:  This  module  will  have  the  user  comnand  checked 
for  validity  and  if  valid  will  have  it 
executed. 

Calling  Modules:  det-.valid_.oonn) 

Modules  Called:  validat^u8er_coumand,  execute_cxxnmand 

Global  Variables  Used:  None 
Globed  Variables  Changed:  None 

Author:  Ronald  K.  Miller 

System:  VAX  13/780,  VMX  O/S  and  UNIX  O/S:  testing  only 


*/ 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

*/ 

V 

V 


/A***************************************************************/ 

execute_user_oonmand  () 
begin 

if  ( validate_user_caiinand  () ) 
begin 

execute_ooumand() ; return  (1) ; 
end 


aid 


retum(O) ; 


£ 
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****************************★**********************************/ 

V 

V^imT^USQLOOMHHJD  */ 

V 

Date:  1  Sept  1983  */ 

Version:  1.2  V 

V 

Name:  validat^_user_oonsnand  */ 

Nodule  Number:  1.2.3.5.1  V 

Function:  This  module  will  check  to  see  if  the  proper  */ 

file  is  being  requested  by  the  authorized  user  */ 
and  if  the  files  are  located  on  the  disk.  In  */ 
the  case  of  a  FUN  command  this  module  will  */ 

also  check  to  see  if  the  requested  file  is  an  */ 
executable  file.  */ 

V 

Calling  Nodules:  execut e_use r_cxxmnand  */ 

Nodules  Called:  chk_rurx_file,  chl^filename,  */ 

chk_user_name  */ 

*/ 

Global  Variables  Used:  end  */ 

Global  Variables  Changed:  None  V 

*/ 

Author:  Ronald  K.  Hiller  */ 

System:  VAX  11/780,  VHS  O/S  and  UNIX  O/S:  testing  only  */ 


val  ida  te_use  r_command  () 
begin 

switch (end) 
begin 

case  1 :  {if  (chkJEilename  ()  &&  chk_user _pame()  &&  chk_run_file()) 
return  (1) j 
return(O) ;} 

/*  return  (1)  if  all  three  are  valid  */ 
/*  otherwise  will  return (0)  V 

case  2:  case  4:  {if  (chkJEilenameO  &&  chkjuserjnameO) 

return (1) ; 
return  (0) ;} 

case  3:  {if  (chk_filename()  &&  chk_userjname()  6& 
!chk_rur\_file())  return(l); 
return (0) ;} 

case  5:  return (1) ;  /*  directory  command  automatically  valid  */ 
default:  retum(O); 


***************************************************************'/ 

V 

an^pILENAME  V 

*/ 

Dates  1  Sept  1983  */ 

Version:  1.0  */ 

V 

Name:  chk_filename  */ 

Module  Number:  1.2.3.5.1.1.1  */ 

Function:  This  module  will  check  to  see  if  the  file  */ 
being  requested  is  located  on  the  disk.  V 

V 

Calling  Modules:  v?lidate_UBer_con«nand  */ 

Modules  Called:  open,  error,  close  */ 

V 

Global  Variables  Used:  conxnancLtable.pararoeterl  */ 

Global  Variables  Changed:  None  */ 

V 

Author:  Ronald  K.  Miller  */ 

System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 


chkJEilenameO 

begin 

if  (fd-(open{cannand_table.paranieterl,0) )  —  H*RCR) 
begin 

error  (2) ;  /*  if  file  can  not  be  open  the  */ 

return  (0) ;  /*  file  is  not  on  the  disk  */ 

«d 
else 
begin 

get_usemame  ( f d)  j 

close  (fd);  /*  else  close  the  file  and  return  (1)  */ 

retum(l) ; 
end 
end 
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/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 


*************************************************************** 


'/ 


CBRjaNJTLE 


Date:  5  Sept 
Version:  1.0 


1983 


Mane:  chK_nx>_file 
Module  Number:  1.2.3. 5.1. 1.3 

Function:  This  module  is  to  determine  if  the  file  being 
requested  is  an  executable  file.  Will 
return (1)  if  so  otherwise  will  return (0) . 

Calling  Modules:  validat^_user_conoand 
Modules  Called:  stringcnp 

Global  Variables  Used:  coomancLtable.parameterl 
Global  Variables  Changed:  None 

Author:  Ronald  K.  Miller 

System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only 


V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

*/ 

V 

V 

*/ 

V 


chKjniufileO 

begin 

char  temp[3]  ,*ccm; 
int  i,j; 
i  -  j  -  0; 

com  -  "COM"; 

while (con*nand_table.parameterl [ i++]  I- 

/*  Find  the  extension  part  of  the  */ 


while  (j  <  3)  /*  filename  */ 

tempi  j++]  ■  oommand_table.paraneterl  [  i++] ; 

/*  Place  the  extension  in  a  */ 

if  (stringcnp  (can,  temp) )  /*  temporary  buffer  for  ccnparsion  */ 
begin 

if (cmd  ”  3)  error (11);  /*  error (11)  means  an  executable  */ 

return(l) ;  /*  file  is  trying  to  be  ran  */ 

end 

if  (cmd  —  1)  error  (10);  /*  error  (10)  means  a  nonexecutable  */ 

return  (0) ;  /*  file  is  trying  to  be  printed  */ 

end 

\ 
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V 


z****************************************************************z 


CtlK  DStik  NAME 


Date:  5  Sept  1983 
Version:  1,0 


JvJOl 


Name:  chk_user _pame 
Nodule  Nunber:  1.2.3.5.1.1.2 

Function:  This  module  will  check  to  make  sure  that  the 
proper  user  is  requesting  their  own  file. 

Calling  Nodules:  val ida t^_use r_ocrarnand 
Nodules  Called:  stringcmp 

Global  Variables  Used:  userblocks  [portno]  .usernm, 

file_usemame 

Global  Variables  Changed:  None 
Author:  Ronald  K.  Miller 

System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only 


chk^user_name  ( ) 
begin 

if  (stringcnp(fila_usemame,userblocks  [portno]  .usernm) ) 
return (1); 
error  (3) ; 
return  (0) ; 


♦ft*************************************************************/ 


GETLOSERNAME 


Date:  5  Sept  1983 
Version:  1.0 


Mane:  getjusemame  */ 

Module  Number:  1.2 .3 .5 .1.1 .1.2  */ 

Function:  Ibis  module  will  get  the  user  name  of  the  file  */ 
being  requested.  This  is  in  order  to  check  */ 
for  user  authority  in  a  later  module.  */ 

V 

Calling  Modules:  chK_filename  */ 

Modules  Called:  None  V 

V 

Global  variables  Used:  opened_files,  filejusemame,  */ 


Global  Variables  Changed:  filejusemame  */ 

V 

Author:  Ronald  K.  Miller  V 

System:  VAX  11/780,  VMS  0/8  and  UNIX  O/S:  testing  only  V 

*/ 


get_usemame  (fd) 
begin 

int  i,j; 

j-BEGINUSER; i«0 ; 
while (j  <  ENDUSER+1) 
filejusemame  [  i++] 
return; 
end 


cpenecLfiles  [fd,  j++] ; 


/ 

/ 

/ 

/ 

/ 

/’ 

/’ 

/’ 

/’ 

/’ 

/’ 

/’ 

/’ 

/< 

/’ 

/' 

/' 

/* 

/* 

/* 

/' 

/' 

/* 

/' 

/' 


ft**************************************************************/ 


*/ 

OPEN  */ 

V 

Date:  6  Sept  1983  */ 

Version:  1,3  */ 

V 

Name:  open  */ 

Module  lumber:  1.2 .3 .5 .1.1  .1J.  */ 

Function:  This  module  opens  a  file  from  disk  and  then  */ 

allows  for  reading  from  and  writing  to  the  */ 

particular  file.  */ 

*/ 

Calling  Modules:  chkjEilename  */ 

Modules  Called:  get_di rectory  */ 

*/ 

Global  Variables  Used:  file_usemame,  openecLfiles,  name,*/ 

NOMSEC,  BCFLENGTH,  BOFSIZE,  */ 

DIRTOACK,  DIRSECPOR,  file,  dtrack,*/ 
dsector,  del_track,  del^_sector  */ 

Globed  Variables  Changed:  fileuaemame,  openecLfile  */ 

V 

Author:  Ronald  K.  Miller  */ 

System:  VAX  11/780,  VMS  C/S  and  ONIX  O/S:  testing  only  */ 

*/ 


open(file,oode) 
char  file[]i 
int  code; 
begin 

int  i,j,k,location; 

char  buffer  [BOFSIZE]  IBOFLENGTB] ; 

dtrackHDIP3RACK;dsector»4DIRSBCrCR; 

finished  »  0; 

while  ( If inished) 

begin 

read (dtrack, dsector, buffer) ; 

/*  Reads  in  a  block  of  the  directory  */ 
/*  and  places  it  into  buffer.  */ 

i»0; 

while  ((i  <  BOFLaxrm)  &&  (buffer [i,0]  !■  EOF)) 

/*  Check  of  end  of  buffer  or  the  end  */ 
/*  of  the  directory.  */ 

begin 

k>4; 

while  (k  <  NAMESIZE) 
begin 

name [k] -buffer [i]  Ik];/*  Places  each  filename  into  name*/ 
k++;  /*  for  ccmparision.  */ 

end 

if  (stringcmp(name,file))  /*  If  the  names  are  the  same  */ 
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*/ 

*/ 


begin 
j  -  0; 


/*  Place  into  openecLfile 
/*  and  then  return(l) . 


del_  track  *  dtrack;  /*  Track  and  sector  of  where 

del_sector  »  dsector;  /*  the  filename  is  located 

/*  in  the  directory. 

while  (j  <  BDPSIZE) 
begin 

cpened_files [location]  [j]  -  buffer [i]  [j]; 
j++; 


end 


location++; 
return  (location  -  1)  j 
end 


V 
*/ 

V 


i++; 

end 

if  (i  «  BDELENGTB) 

/*  If  true  means  the  entire  directory  V 
begin  /*  has  not  be  read.  Therefore  another  */ 

dsector -H-;  /*  sector  needs  to  be  read  in.  If  */ 

/*  the  last  sector  on  the  track  has  been  */ 
/*  need  to  go  to  next  track  and  sector  0.*/ 
if  (dsector  >  NOMSEC) 
begin 
dtrack++; 
dsector  *  0; 
end 
end 

else  return  (-1) ;  /*  return  (-1)  means  reached  aid  of  the  V 
/*  directory  and  no  file  was  found.  V 


/A***************************************************************/ 

/*  V 

/*  ERROR  */ 

/*  V 

/*  Dates  6  Sept  1983  */ 

/*  Version:  1.5  */ 


/*  Name:  error  */ 

/*  Module  Number:  1.2.3 .5 .1.1 .1.3  */ 

/*  Function:  This  module  will  determine  error  received  and  */ 

/*  will  build  the  necessary  error  message.  V 

/*  */ 

/*  Calling  Modules:  de t_val i<3_oocm ,  chk_filename,  */ 

/*  chKjuserjname,  execute^ooramand,  */ 

/*  chKjspace  */ 

/*  Modules  Called:  transmit-jnessage  */ 

/*  V 

/*  Globed  Variables  Used:  message,  MESSIZE  */ 

/*  Global  Variables  Changed:  message  */ 

/*  V 

/*  Author:  Ronald  K.  Miller  */ 

/*  System:  VAX  13/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/A***************************************************************/ 

error (type) 
int  type; 
begin 

switch  (type) 
begin 

case  1:  {  strcpy (message, 

"SYNTAX  ERRCR  \ji") ; 

break;} 

case  2:  {  strcpy  (message, 

"INVALID  FILENAME  \fl") ; 

break;} 

case  3:  {  strcpy (message, 

•INVALID  USER  ATTEMPTING  TO  RETRIVE  FILENji") ; 
break;} 

case  4:  {  strcpy (message, 

•ILLEGAL  USER  \n") ; 

break;} 

case  5:  {  strcpy (message, 

"UNAUTHORIZED  USER  W) ; 

break;} 

case  6:  {  strcpy (message, 

•UNREOCNIZEABLE  OCCE  -  TRY  AGAIN  \p") ; 

break;} 

case  7:  {  strcpy (message, 

•NOT  ENOUGH  MEMORY  SPACE  TO  EXECUTE  NON  W) ; 
break;} 

case  8:  {  strcpy (message, 


/****************************************************************y 


TEANSMITJESSAGE 


Date:  7  Sept  1983 
Version:  1.0 


/*  Name:  trananitjnessage  */ 

/*  Module  lumber:  1.2 .3 .1.2.1  */ 

/*  Function:  This  module  is  to  transmit  any  message  */ 

/*  received  to  the  correct  user.  */ 

/*  V 

/*  Calling  Modules:  error,  buildjoessage  V 

/*  Modules  Called:  None  V 

/*  V 

/*  Global  Variables  Used:  None  */ 

/*  Global  Variables  Changed:  None  V 

/*  V 

/*  Author:  Ronald  R.  Miller  */ 

/*  System:  VAX  13/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

yHHM*MMHW**H*WH*H***<HH>WW*H**<Ht*iWnHHt******0**Y 

tranaaitjnessage  (string) 
char  string  [] ; 
begin 
int  i; 
i-0; 

do  begin 

while  ((inp(ports(portno]  .statport)  & 

ports [portno] .sendbit)  «*  0) ; 
outp  (ports [portno] .dataport,string[ij) ; 

6i)d 

while  (string  [i++]  1«  'Vi'); 
return; 


/ft***************************************************************/ 

/*  V 

/*  REM)  */ 


/*  Date:  7  Sept  1983  */ 

/*  Version:  1.2  */ 

/*  V 

/*  Name:  read  */ 

/*  Module  Nunber:  1.2.3 .5.2.1 .3  */ 

/*  Function:  To  read  a  sector  from  the  disk  when  given  the  */ 

/*  track  nunber  and  sector  nunber  to  read.  */ 

/*  V 

/*  Calling  Modules:  open  */ 

/*  Modules  Called:  None  */ 

/*  V 

/*  Global  Variables  Used:  None  */ 

/*  Global  Variables  Changed:  None  */ 

/*  */ 

/*  Author:  Ronald  K.  Miller  */ 

/*  System:  VAX  13/780,  VMS  Q/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/****************************************************************/ 

read (track , sector , inbuf ) 
int  track, sector; 
char  inbuf [BDFSIZE]  [BUFLENGTB] ; 
begin 

int  k,i,j; 
char  c; 

i  *  j  ■  k  “  0; 
while  (k  <  EKHL^IZE) 
begin 

while  ( ( inp(DISKSTAT)  &  DISKRDA)  —  0); 
c  ■  inp(DISKFORT) ; 

Inbuf  [i]  [j]  -  c;  j++; 

if  (c  ”  EOF)  finished  ■  1;  /*  When  EOF  reached  the  entire  */ 
if  (j  ■*  BUFLENGTH)  /*  file  has  been  read  in.  */ 

begin 

i++;  j  ■  0; 
end 
k++; 
end 

return; 
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butld__barseltable 


Date:  7  Sept  1983 
Version:  1.4 


/****************************************************************/ 
/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 

/* 


Name:  build_parse_table 
Nodule  Number:  1.2.2.3 

Function:  Hiis  module  will  break  the  command  line  into 
its  different  parameters. 

Calling  Modules:  p_cccin_line 
Modules  Called:  None 

Globed  Variables  Used:  ccmmancLline ,  command_table 
Global  Variables  Changed:  commancLtable 

Author:  Ronald  K.  Miller 

System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only 


V 

V 

V 

V 

V 

V 

V 

*/ 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 


/ft***************************************************************/ 


build_parse_table  ( ) 
begin 

♦define  BLANK  '  '  /*  defines  a  blank  */ 

int  i,j,k,l,m; 
i«j-k»l«m*0; 
while  (1  <  CGMMSIZE) 
begin 

ccmmand_table.oommand[l]  =  BLANK; 
ccmmancLtable. parameter!  [  1]  » 

ocranand_table.parameter2tl]  =  BLANK; 

1++? 

end 

while  (1  <  PARASIZE) 
begin 

cannand_table.parameterl  [  1]  - 

ooranand_table.parameter2[l]  *  BLANK; 

1++; 

end 

while  (coranand_line[i]  1*  BLANK  &&  command_line[i]  1=  'Vi') 
commancLtable .  command  [  j++]  ■  ooranand_line[i++] ; 
while  (cornnand_line [ i-H-]  **  BLANK); 
if  (ccmmancLline[iI  ®®  '\n') 
begin 

commancLtable.  rsumper  am  ®  0; 
return; 
end 

while  (corarand_line [i]  l®  BLANK  &&  command_line[i]  I*  '\n') 
ccmmand_table .  pa r ane te rl  [  k++]  ®  oommand_line[i++] ; 
while  (command_line[i++]  «®  BLANK); 
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if  ( cxaimancLline  [  i  ]  =  '\n') 
begin 

oonanan(l_table.nuinparan  »  1; 
return; 
end 

while  (conroan4J.ine[i]  1«  BLANK  &&  caranand_line [ i ]  !*  '\n') 
comnand_table .  par aneter2  [m++]  ■  ooranand_line  [  i++] ; 
cctmand_table . numpa r an  «  2; 
return; 


/ ** **************************************************************/ 


/*  V 

/*  EXCEUTELGOMMAND  */ 

/*  V 

/*  Date:  9  Sept  1983  */ 

/*  Version:  2.1  */ 

/*  */ 

/*  Mane:  execute_oonmand  */ 

/*  Module  Number:  1.2.3 .5.2  */ 

/*  Function:  This  nodule  will  execute  a  given  user  command  */ 

/*  only  after  the  command  has  been  determined  to  */ 

/*  be  valid.  */ 

/*  */ 

/*  Calling  Modules:  execute_user_coranand  V 

/*  Modules  Called:  get_file,  send_file,  processL_scheduler  */ 

/*  V 

/*  Global  Variables  Used:  and  */ 

/*  Global  Variables  Changed:  None  */ 

/*  V 

/*  Author:  Ronald  K.  Miller  */ 

/*  System:  VAX  11/780,  VMS  Q/S  and  UNIX  O/S:  testing  only  */ 

/*  V 


/**•** ************************************************************/ 

execute_ooranand  {) 
begin 

switch  (and) 
begin 
case  1: 
case  2: 

case  3 :  {  if  (getvJ:  ile  (atoi  (openecLfiles  [fd, BEG3RACK] ) , 

atoi  (openecLf  iles  [fd,BEGSECK3R] ) ) ) 
process_scheduler() ;  break;  } 
case  4:  {  if  (getjfilefdel^trackrdel^sector) ) 
process_scheduler () ;  break;  } 
case  5:  {  if  (gebjE ile (DIRTOACK, DIRSECPOR) ) 
processjBcheduler() ;  break;  } 
default:  {  error (6) ;break;  } 
end 


return; 


***************************************************************/ 

V 

GET3UTLE  */ 

V 


Date:  9  Sept  1983 
Version:  1.2 


/*  Mane:  get_file  */ 

/*  Module  Number:  1.2.3 .5 .2.1  */ 

/*  Function:  This  module  preforms  all  the  necessary  */ 

/*  functions  to  run  an  executable  file.  V 

/*  V 

/*  Calling  Modules:  executs_.coranand,  buildjpcb  */ 

/*  Modules  Called:  read,  chkjapace  */ 

/*  V 

/*  Globed  Variables  Used:  openecLfiles,  BEGSIZE,  size,  */ 

/*  begin_address,  end_address  */ 

/*  Global  Variables  Changed:  begir\_address,  end_address  */ 

/*  V 

/*  Author:  Ronald  K.  Miller  */ 

/*  System:  VAX  11/780,  VMS  (VS  and  UNIX  O/S:  testing  only  */ 

/*  V 

/****************************************************************/ 

getJEile (track, sect or) 
int  track, sector; 
begin 

int  i,j; 
char  char  size; 

charsize  «  openecLfiles [fd, BEGSIZE] ; 


size  »  atoi  (charsize) ;  /*  Converting  a  string  to  integer  */ 

if  ( Ichkjspace (size) )  /*  to  check  if  enough  space  */ 

begin 

error (7) ;  /*  Not  enough  space  to  put  the  */ 

return  (0) ;  /*  program  into  main  memory  */ 

aid 

builc|_pcb  (and-1) ; 
finished  =  0; 

begin_address[number_jobe]  *  manoryJLoc; 

/*  this  sets  the  first  location 
/*  where  the  program  is  being 
/*  placed 

pcb[portno]  ,offset_address  »  manory__loc; 
track  «  opened_files[fd,BEGTOACX]; 
sector  »  opened_files[fd,BBGSECTOR]; 
while ({finished) 
begin 

read  (track,  sect  or  ,memory_J.oc) ; 
roeroory_J.oc  ■  memoryJLoc  +  BXTELSIZE; 
track  «  manory_J.oc  -  2; 
sector  ■  memory_loc  -  1; 
if (track  “  sector  ■»  0) 


finished  -  1; 
if  (and  **  4) 

finished-  1;  /*  If  delete  command  only  need  to 
/*  read  one  sector  fran  the  disk. 
manory_loc  ■  memory_loc  -  2; 

/*  Don't  want  to  have  the  next 
/*  track  and  sector  in  memory, 
end 

encLaddress  [nunber_jobe]  -  memoryJLoc  -  EOTELSIZE; 

/*  This  sets  the  last  location 
/*  where  the  progran  is  begin 
/*  placed. 

pcb[portno]  ,final_address  -  manory_loc  -  EHT5J5IZE; 
pcbiportnoj  ,io_jstatus  -  0; 

/*  The  process  is  no  longer  in  i/o  wait 
number__jcbe++;  /*  Total  number  of  jobs  in  the  system. 


V 

V 

V 

V 


V 

V 

V 


V 

V 


/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 


***************************************************************/ 

V 

CHIL3PACE  */ 

V 

Date:  13  Sept  1983 
Version:  1.2 


Mane:  chKjapace 

Module  Number:  1.2 .3 .5.2.1 .1 

Function:  This  nodule  will  determine  if  there  is  enough 
space  in  main  memory  to  place  the  incoming 
program. 

Calling  Modules:  get_file 
Modules  Called:  sort 

Global  Variables  Used:  size,  begir\_addressf  encLaddress, 

order,  nunber_jobe,  BASEJVDCRESS, 
TOP JCERESS 

Global  Variables  Changed:  None 
Author:  Ronald  K.  Miller 

System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only 


V 

V 

V 

V 

V 
*/ 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 

V 


chk_spaoe (size) 
int  size: 
begin 

int  i,j,k,l,bottcm; 
i  ■  j  *  k  *  0? 

if  (number_jobe>l)  /*  if  the  more  than  one  job  on  the  system  */ 
sort(order) ;  /*  the  location  must  be  sorted  from  largest  */ 

/*  to  smallest.  Hie  sorted  order  is  placed  */ 
/*  in  the  array  called  order.  */ 

else  if (number_jabe  ™  0) 
order [0]  -  MAXJCBS; 

/*  If  no  jobs  on  the  system  order  must  be  */ 
/*  initialized  and  this  make  the  first  value*/ 
/*  equal  to  TOP_JDERESS.  */ 

else 

begin 

order [0]  ■  0;  /*  If  only  one  job  order  must  be  inialized.  */ 

order [1]  «  MAXJCBS; 
end 

i  -  carder  [j] ; 
bottom  -  BASELfiDERESS; 

/*  bottom  is  use  to  find  how  much  free 
/*  space  is  located  between  jobs, 
while (k  <  number_jobe+l) 
begin 

if(8ize  <-  (begir\_address[i] -bottom)) 


V 

V 


begin 

nwnory_loc  ■  bottom; 
return  (1) ; 

/*  Make  memoryJLoc  equal  to  the  last  entry  */ 
/*  between  jobs  and  then  return (1) .  */ 

end 

if  (k  —  0) 
begin 
error  (8) ; 
return  (0) ; 
end 

bottom  -  end_address[i] ; 

/*  Move  bottom  to  the  last  location  of  the  */ 
/*  next  job.  */ 

i  -  order [j++3; 
k++; 
end 

error (7) ; 
return (0) ; 
end 


/*  SORT  */ 

/*  V 

/*  Date:  13  Sept  1983  V 

/*  Version:  1.1  */ 

/*  V 

/*  Name:  sort  */ 

/*  Nodule  Nuaber:  1.2 .3 .5. 2.1 .1.1  V 

/*  Function:  This  nodule  will  sort  the  first  location  of  */ 

/*  each  job  in  memory  and  place  the  indicies  */ 

/*  values  in  the  array  called  order.  */ 

/*  V 

/*  Calling  Nodules:  chk_space  */ 

/*  Nodules  Called:  None  */ 

/*  */ 

/*  Global  Variables  Used:  order,  begin_address,  number_jobe  */ 

/*  Global  Variables  Changed:  order  */ 

/*  */ 

/*  Author:  Ronald  K.  Miller  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/it***************************************************************/ 

sort (order) 
int  order  [] ; 
begin 

int  i,j,k,l,lowest,aount,teap[MAXJGBS]7 
i  ■  k  -0; 

j  «l! 

count  ■  nunber_jobe; 
lowest  ■  0; 

for  ( 1-0  ;nt«nber_job6-l ;  1++) 
temp[l]  ■  begin_address[l] ; 

/*  Place  the  array  of  beginning  address  */ 
/*  into  a  temporary  array  called  temp.  */ 
while  (k  <  nunber_jobs) 
begin 

while  (j  <  number_jobe) 
begin 

if(temp[j]  <  temp  [lowest]) 

/*  Find  the  lowest  memory  location.  */ 

lowest  -  j  7 


lowest  - 

j++7 

and 

order [i++]  ■ 
temp  [lowest] 


lowest  7 

«  TDP_ADERESS; 

/*  Make  the  smallest  location  the  */ 

/*  largest  value  possible  V 

/*  Start  from  the  top  of  the  array  again*/ 


lowest  *  O7 


Date:  14  Sept  1983 
Version:  1.1 


/*****************************************************★**********/ 

/*  V 

/*  SQJD_fTLE  */ 

/*  V 

/*  Date:  14  Sept  1983  */ 

/*  Version:  1.1  */ 

/*  V 

/*  Name:  send_file  */ 

/*  Module  tfcmber:  1.2.3.5.2.2.3.1  */ 

/*  Function:  This  module  will  transmit  a  file  to  the  user  */ 

/*  or  the  printer  depending  on  what  was  requested.*/ 

/*  This  file  has  already  been  placed  into  main  */ 

/*  memory.  */ 

/*  V 

/*  Calling  Modules:  process_acheduler  */ 

/*  Modules  Called:  None  */ 

/*  V 

/*  Global  Variables  Used:  None  */ 

/*  Global  Variables  Changed:  None  */ 

/*  */ 

/*  Author:  Ronald  K.  Miller  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/A***************************************************************/ 


sencLf  lie  (por  t_num) 
int  port _num; 
begin 

int  start; 
char  value; 

start  >  pcb[portno] .offset_address; 

/*  Inialize  start  to  the  beginning*/ 
/*  address  in  main  memory.  */ 

value  -  inp(start) ;  /*  Take  the  first  character  from  */ 

/*  memory.  */ 

while (  value  I*  EOF) 
begin 

while  ( ( inp (ports  [portjTum]  .statport)  & 

ports [por t_num] .sendbit)  ■»  0) ; 
outp (ports [portjTum] .dataport, value) ; 
value  «  inp(++start) ; 
end 

return; 


***************************************************************/ 


DEALLOCATEJJSPACE 


Date:  7  Oct  1983 
Version:  1.0 


/*  None:  deallocate_space  */ 

/*  Nodule  Ninfcer:  1.2.3.5.2.2.3.3  */ 

/*  Function:  This  nodule  frees  the  area  of  main  memory  that  */ 

/*  a  completed  process  was  occupying.  This  is  */ 

/*  done  by  shifting  the  address  a  row  up  and  V 

/*  deer  anen ting  the  number  of  jobs  on  the  system.  */ 

/*  V 

/*  Calling  Modules:  cleanjp,  procesgjscheduler  */ 

/*  Modules  Called:  None  */ 

/*  V 

/*  Global  Variables  Used:  portno,  begin_address,  */ 

/*  encLaddress  */ 

/*  Global  Variables  Changed:  begin_address,  encLaddress  */ 

/*  V 

/*  Author:  Ranald  K.  Miller  */ 

/*  System:  VAX  11/780,  VMS  C/S  and  UNIX  O/S:  testing  only  */ 

/*  V 

/*************************************************************«**/ 

deallocate_space (row) 
int  row: 
begin 
int  i; 

for ( i-row  ;number_jobe-l ; i++) 
begin 

begin_addres8[i]  ■  begin_address[i+l] ; 

/*  Shift  the  beginning  and  */ 

/*  ending  address  up  one  row  */ 

encLaddress [i]  »  encLaddress [i+1] ; 
end 

nunber_jcbe — ; 
return; 


Appendix  F 
AMOS  Users'  Guide 

This  is  the  user  guide  for  AMOS.  It  covers  the 
procedures  to  follow  for  interfacing  with  the  operating 
system.  The  procedures  covered  are: 

1.  Log-in 

2.  Log-off 

3.  User  help 

4.  System  changes 

5.  User  commands 

Log-in 

The  procedure  to  log-in  consist  of  sending  a  carriage 
return  (<CR>) .  This  can  be  done  by  either  typing  in  a  line 
of  text  ended  by  a  <CR>  or  by  entering  a  single  <CR>.  The 
system  will  prompt  the  user  for  a  username.  This  prompt 
will  be: 

USERNAME : 


The  user  must  input  their  username  followed  with  a 
<CR>.  The  system  will  prompt  the  user  for  a  password. 


This  prompt  will  be: 


PASSWORD: 

The  user  must  input  their  password  followed  with  a 
<CR>.  If  both  username  and  password  are  valid,  the  system 
will  return  the  following  message: 

Log-in  complete... 

If  either  the  username  or  password  is  invalid,  the 
system  will  return  the  following  message: 

ILLEGAL  USER 

Log-off 

For  the  user  to  terminate  interaction  with  the 
operating  system,  the  user  must  log-out.  The  following 
message  must  be  typed  by  the  user  to  successfully  log-out: 


BYE<CR> 


The  system  will  respond  with  the  following  message: 


Logged  out... 

User  Help 

The  user  can  ask  for  system  or  command  information. 
The  format  for  the  help  command  is: 

HELP  ' subject' <CR> 

The  'subject'  for  system  information  can  be  either 
USERS  or  DEVS.  The  'subject'  for  command  information  can 
be  one  of  the  following: 

RUN 

LIST 

PRINT 

DEL 

DIR 

For  the  system  information  the  operating  system  will 
return  the  users  on-line  for  USERS  or  the  devices  on-line 
for  DEVS.  For  the  command  information  the  operating 
system  will  return  the  following  for  the  respective 


commands : 


Format:  RUN  FILENAME  (executable  file) 

Format:  LIST  FILENAME 

Format:  PRINT  FILENAME  (nonexecutable) 

Format:  DEL  FILENAME 
Format:  DIR 

If  the  'subject'  cannot  be  matched  with  the  available 
information,  the  system  will  respond  with  the  following 
message : 

No  help  is  available  for  that  command 

System  Changes 

To  reconfigure  the  system  the  user  must  be  logged-in 
under  the  'Superuser'  username.  The  current  permissible 
changes  are  adding  a  username  and  deleting  a  username. 
The  following  is  the  format  for  the  two  system  changes 
command : 

SYS  ADDUSER<CR> 


SYS  DELUSER<CR> 


I 


I 


% 


In  each  case  the  system  will  prompt  the  'Superuser' 
for  the  desired  username.  This  prompt  will  consist  of: 


USERNAME: 


The  'Superuser'  must  then  input  the  username, 


User  Commands 


The  user  commands  are  listed  in  the  Help  User  section 
of  this  appendix.  The  following  is  the  required  format 
for  each  command: 

RUN  ' filename '<CR> 

LIST  ' filename ' <CR> 

PRINT  ' filename ' <CR> 

DEL  ' filename' <CR> 

DIR<CR> 


f: 


The  'filename'  for  the  RUN  command  must  be  an 
executable  file.  The  'filename'  for  the  PRINT  command 
must  be  a  nonexecutable  file. 
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If  'filename'  is  not  located  in  secondary  memory,  the 


system  will  respond  with  the  following  message: 


F-5 


VC- ’• 


INVALID  FILENAME 


If  ’filename’  for  the  RUN  command  is  not  an 
executable  file  the  system  will  respond  with  the  following 
message: 

NONEXECUTABLE  FILE  UNABLE  TO  RUN 

If  'filename'  for  the  PRINT  command  is  an  executable 
file  the  system  will  respond  with  the  following  message: 

EXECUTABLE  FILE  UNABLE  TO  PRINT 

If  the  username  of  the  file  being  accessed  isn't  the 
same  as  the  user's  username,  the  system  will  respond  with 
the  following  message: 

INVALID  USER  FOR  FILE 

If  all  the  above  is  valid  but  there  isn't  enough 
space  in  main  memory  for  execution  of  the  job,  the  system 
will  respond  with  the  following  message: 


NOT  ENOUGH  MEMORY  SPACE  TO  EXECUTE  NOW 


If  the  job  is  too  large  for  all  of  main  memory,  the 
system  will  respond  with  the  following  message: 

PROGRAM  TOO  LARGE  FOR  MEMORY 

If  no  errors  occur,  the  command  will  be  executed. 
Upon  completion  of  the  job's  execution,  the  system  will 
respond  with  the  following  message: 

Processing  of  job  complete... 

If  the  job's  execution  is  aborted  at  any  time,  the 
system  will  respond  with  the  following  message: 

PROCESS  ABORTED,  DID  NOT  COMPLETE 

Other  Error  Messages 

If  the  user  does  not  input  one  of  the  above  command 
formats,  the  system  will  respond  with  the  following 
message: 

SYNTAX  ERROR 

If  any  new  commands  are  added  to  AMOS,  the  formats 
for  the  new  commands  must  be  documented. 


Appendix  G 

Hierarchical  Structure  of  Design 

This  appendix  presents  the  overall  design  in 
hierachical  form.  The  hierarchical  concept  is  based  on 
the  leveling  of  the  extended  machine  concept  (Ref.  7: 
15-20).  The  AMOS  design  can  be  presented  in  five  levels 
that  are  layered  around  the  "bare  machine”,  or  computer. 
The  following  is  the  five  levels  of  the  hierarchical 
structure  presented: 

1.  Level  1:  Lower  level  Process  Scheduler  modules 
and  any  modules  directly  involved  in  the  bare 
machine. 

2.  Level  2:  Memory  Management  Modules. 

3.  Level  3:  Higher  level  Process  Scheduler  modules. 

4.  Level  4:  Device  Management  Level. 

5.  Level  5:  High  Level  Operating  System  Control. 

The  charts  present  the  design  using  the  hierarchy 
chart.  The  circles  with  the  numbers  inside  indicate  what 


level  the  next  module  is  located  or  what  level  the 
previous  module  is  located. 
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